|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
Network Working Group Internet Engineering Task Force
Request for Comments: 1122 R. Braden, Editor
October 1989
Требования к хостам Internet - коммуникационные уровни
Статус документа
В данном RFC содержатся официальные спецификации сообщества Internet.Документ собержит ссылки, исправления и дополнения к первичным стандартам протоколов, имеющим отношение к хостам. Документ можно распространять свободно.
Аннотация
Этот документ является одним из двух RFC, посвященных определению и обсуждению требований к программам хостов Internet.Этот документ посвящен коммуникационным протоколам, а второй документ RFC-1123 - прикладным протоколам и протоколам поддержки.
Оглавление
Требования к хостам Internet .......................................................................................................................... 1
Статус документа ........................................................................................................................................ 1
Краткое изложение ..................................................................................................................................... 1
1. Введение ................................................................................................................................................. 4
1.1 Архитектура Internet ........................................................................................................................ 4
1.1.1 Хосты Internet .......................................................................................................................... 4
1.1.2 Архитектурные допущения ...................................................................................................... 5
1.1.3 Стек протоколов Internet ........................................................................................................ 5
1.1.4 Встроенная маршрутизация ..................................................................................................... 6
1.2 Общие вопросы ................................................................................................................................ 7
1.2.1 Постоянное изменение Internet ................................................................................................ 7
1.2.2 Принципы устойчивости ......................................................................................................... 7
1.2.3 Протоколирование ошибок ...................................................................................................... 7
1.2.4 Конфигурационные параметры ................................................................................................ 8
1.3 Работа с документом ....................................................................................................................... 8
1.3.1 Структура документа ............................................................................................................... 8
1.3.2 Требования .............................................................................................................................. 9
1.3.3 Терминология .......................................................................................................................... 9
1.4 Благодарности ............................................................................................................................... 10
2. Канальный уровень ............................................................................................................................... 11
2.1 Введение ........................................................................................................................................ 11
2.2 Общие вопросы .............................................................................................................................. 11
2.3 Частные вопросы ............................................................................................................................ 11
2.3.1 Согласование трейлерного протокола .................................................................................. 11
2.3.2 Протокол преобразования адресов - ARP .............................................................................. 11
2.3.2.1 Проверка кэша ARP ......................................................................................................... 11
2.3.2.2 Очередь пакетов ARP ...................................................................................................... 12
2.3.3 Инкапсуляция Ethernet и IEEE 802 ......................................................................................... 12
2.4 Интерфейс между канальным уровнем и уровнем INTERNET ......................................................... 13
2.5 Требования к канальному уровню ................................................................................................. 13
3. Протоколы уровня INTERNET ................................................................................................................. 13
3.1 Введение ........................................................................................................................................ 13
3.2 Общие вопросы .............................................................................................................................. 15
3.2.1 Протокол Internet - IP ............................................................................................................ 15
3.2.1.1 Номер версии: RFC-791, параграф 3.1 .......................................................................... 15
3.2.1.2 Контрольная сумма: RFC-791, параграф 3.1 .................................................................. 15
3.2.1.3 Адресация: RFC-791, параграф 3.2 ............................................................................... 15
3.2.1.4 Фрагментация и сборка: RFC-791, параграф 3.2 ........................................................... 16
3.2.1.5 Идентификация: RFC-791, параграф 3.2 ....................................................................... 16
Перевод на русский язык - Н. Малых 1 rfc.com.ru
|
||
|
|
||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
3.2.1.6 Тип обслуживания: RFC-791, параграф 3.2...................................................................16
3.2.1.7 Время жизни: RFC-791, параграф 3.2............................................................................17
3.2.1.8 Опции: RFC-791, параграф 3.2......................................................................................17
3.2.2 Протокол управляющих сообщений Internet - ICMP..............................................................18
3.2.2.1 Destination Unreachable: RFC-792.................................................................................19
3.2.2.2 Redirect: RFC-792..........................................................................................................19
3.2.2.3 Source Quench: RFC-792................................................................................................20
3.2.2.4 Time Exceeded: RFC-792................................................................................................20
3.2.2.5 Parameter Problem: RFC-792..........................................................................................20
3.2.2.6 Echo Request/Reply: RFC-792........................................................................................20
3.2.2.7 Information Request/Reply: RFC-792..............................................................................21
3.2.2.8 Timestamp and Timestamp Reply: RFC-792....................................................................21
3.2.2.9 Address Mask Request/Reply: RFC-950..........................................................................21
3.2.3 Протокол IGMP (Internet Group Management Protocol)............................................................22
3.3 Частные вопросы............................................................................................................................22
3.3.1 Маршрутизация исходящих дейтаграмм...............................................................................22
3.3.1.1 Выбор Local/Remote.......................................................................................................22
3.3.1.2 Выбор шлюза..................................................................................................................23
3.3.1.3 Кэш маршрутов..............................................................................................................23
3.3.1.4 Обнаружение мертвых-шлюзов......................................................................................24
3.3.1.5 Выбор нового шлюза......................................................................................................26
3.3.1.6 Инициализация..............................................................................................................26
3.3.2 Сборка (Reassembly)...............................................................................................................26
3.3.3 Фрагментация.........................................................................................................................27
3.3.4 Локальные многодомные хосты.............................................................................................28
3.3.4.1 Введение........................................................................................................................28
3.3.4.2 Требования для многодомных хостов..........................................................................29
3.3.4.3 Выбор адреса отправителя.............................................................................................29
3.3.5 Пересылка Source Route........................................................................................................30
3.3.6 Широковещание.....................................................................................................................30
3.3.7 IР МuIticasting........................................................................................................................31
3.3.8 Сообщения об ошибках.........................................................................................................31
3.4 Интерфейс между уровнем IP и транспортным уровнем...............................................................31
3.5 Требования к уровню INTERNET....................................................................................................33
4. Транспортные протоколы.....................................................................................................................36
4.1 Протокол пользовательских дейтаграмм UDP...............................................................................36
4.1.1 Введение................................................................................................................................36
4.1.2 Общие вопросы......................................................................................................................36
4.1.3 Частные вопросы....................................................................................................................36
4.1.3.1 Порты.............................................................................................................................36
4.1.3.2 Опции IP.........................................................................................................................36
4.1.3.3 Сообщения ICMP............................................................................................................36
4.1.3.4 Контрольные суммы1ЮР................................................................................................37
4.1.3.5 Многодомные хосты UDP...............................................................................................37
4.1.3.6 Некорректная адресация...............................................................................................37
4.1.4 Интерфейс между уровнем UDP и прикладным уровнем.......................................................37
4.1.5 Требования к протоколу UDP.................................................................................................37
4.2 Протокол управления передачей - TCP.........................................................................................38
4.2.1 Введение................................................................................................................................38
4.2.2 Общие вопросы......................................................................................................................38
4.2.2.1 Хорошо известные (Well-Known) порты: RFC-793, параграф 2.7...................................38
4.2.2.2 Использование флага Push: RFC-793, параграф 2.8......................................................38
4.2.2.3 Размер окна: RFC-793, параграф 3.1.............................................................................39
4.2.2.4 Указатель важности: RFC-793, параграф 3.1.................................................................39
4.2.2.5 Опции TCP: RFC-793, параграф 3.1...............................................................................39
4.2.2.6 Максимальный размер сегмента: RFC-793, параграф 3.1..............................................39
4.2.2.7 Контрольная суммаТСР: RFC-793, параграф 3.1...........................................................40
4.2.2.8 Диаграмма состояния соединения TCP: RFC-793 параграф 3.2, стр. 23.......................40
Пегэевод на гэусский язык - Н. Малых 2 www.Drotocols.ru
|
||
|
|
||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||||
|
|
||||
|
4.2.2.9 Выбор начального порядкового номера: RFC-793, параграф 3.3, стр. 27 ..................... 40
4.2.2.10 Число последовательных попыток открытия: RFC-793, параграф 3.4, стр. 32 ............ 40
4.2.2.11 Восстановление по старым дубликатам SYN: RFC-793, параграф 3.4, стр. 33 ............. 40
4.2.2.12 Сегмент RST: RFC-793, параграф 3.4 ........................................................................... 40
4.2.2.13 Завершение соединений: RFC-793, параграф 3.5 ........................................................ 40
4.2.2.14 Передача данных: RFC-793, параграф 3.7, стр. 40 ..................................................... 41
4.2.2.15 Тайм-аут повторной передачи: RFC-793, параграф 3.7, стр. 41 ................................. 42
4.2.2.16 Управление окном: RFC-793, параграф 3.7, стр. 41 .................................................... 42
4.2.2.17 Проверка нулевого окна: RFC-793, параграф 3.7, стр. 42 ........................................... 42
4.2.2.18 Пассивные вызовы OPEN: RFC-793, параграф 3.8 ....................................................... 43
4.2.2.19 Время жизни: RFC-793, параграф 3.9, стр. 52 ............................................................. 43
4.2.2.20 Обработка событий: RFC-793, параграф 3.9 ............................................................... 43
4.2.2.21 Подтверждение для сегментов из очереди: RFC-793, параграф 3.9 ........................... 43
4.2.3 Частные вопросы .................................................................................................................... 44
4.2.3.1 Расчет тайм-аута для повторной передачи .................................................................... 44
4.2.3.2 Когда передавать сегмент ACK ..................................................................................... 44
4.2.3.3 Когда передавать Window Update .................................................................................. 44
4.2.3.4 Когда передавать данные .............................................................................................. 45
4.2.3.5 Сбои в соединениях TCP ................................................................................................ 46
4.2.3.6 TCP Keep-Alive ............................................................................................................... 46
4.2.3.7 Многодомные хосты TCP ............................................................................................... 47
4.2.3.8 Опции IP ......................................................................................................................... 47
4.2.3.9 Сообщения ICMP ............................................................................................................. 47
4.2.3.10 Проверка корректности удаленного адреса ............................................................... 47
4.2.3.11 Картины трафика TCP .................................................................................................. 47
4.2.3.12 Эффективность ............................................................................................................. 48
4.2.4 Интерфейс между TCP и прикладным уровнем ...................................................................... 48
4.2.4.1 Асинхронные отчеты ...................................................................................................... 48
4.2.4.2 Тип обслуживания .......................................................................................................... 48
4.2.4.3 Вызов Flush .................................................................................................................... 49
4.2.4.4 Многодомные хосты ....................................................................................................... 49
4.2.5 Требования к протоколу TCP ................................................................................................. 49
5. Литература ........................................................................................................................................... 51
Вопросы безопасности .............................................................................................................................. 53
Адрес автора ............................................................................................................................................. 53
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
3
|
|||
|
|
||||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
1. Введение
Этот документ является первым из пары RFC, определяющих и обсуждающих требования к реализации хост-систем на базе стека протоколов Internet.Документ посвящен коммуникационным протоколам -канальный уровень, уровень IP (сетевой) и транспортный уровень.Второй документ - RFC-1123 Requirements for Internet Hosts -- Application and Support" [INTRO:1]1 - посвящен протоколам
прикладного уровня.С этой парой также тесно связан документ RFC-1009 - Requirements for Internet Gateways [INTRO:2]2.
Документ предназначен для производителей и разработчиков, а также для пользователей коммуникационных программ Internet.Документ написан на основе обобщения опыта работы исследователей Internet и компаний-производителей.
В этом RFC рассмотрены стандарты протоколов, которые должны использоваться на хостах, подключенных к сети Internet, а также связанные с ними RFC и другие документы, описывающие текущие варианты спецификаций для таких протоколов.В документе исправлен ряд ошибок, встречающихся в упоминаемых документах, рассмотрены дополнительные вопросы и даны рекомендации по реализации протоколов.
Для каждого протокола в данном документе также приведен явный набор требований, рекомендаций и опций.Читатель должен понимать, что список приведенных в документе требований неполон - полные требования для хостов Internet содержатся в документах, определяющих спецификации протоколов.В данном RFC приведены поправки, уточнения и дополнения к стандартам протоколов.
Качественная реализация протоколов, подготовленная в результате внимательного прочтения этого RFC, работы в контакте с техническим сообществом Internet и учета позитивной практики разработки коммуникационных программ, не должна сильно отличаться от содержащихся в документе требований. Многие из “требований” данного RFC уже реализованы в стандартах или рассматриваются для включения в стандарты, поэтому их обсуждение в данном документе может показаться избыточным.Однако такие вопросы были включены в документ, поскольку некоторые из имеющихся реализаций содержат ошибки, приводящие к недостаточной интероперабельности, снижению производительности и возникновению иных проблем.
В документе обсуждается и разъясняется множество требований и рекомендаций.Простой список требований может быть опасен по ряду причин:
♦ некоторые требуемые функции более важны, а ряд функций не является обязательным;
♦ существует множество причин, по которым продукция, разработанная для ограниченного контекста может быть выбрана для использования в иных средах.
Нужно следовать приведенным в документе спецификациям для обеспечения интероперабельности хостов при взаимодействии через разнородные и сложные системы Internet.Хотя многие из числа имеющихся реализаций не соответствуют тем или иным требованиям, спецификации являются идеалом, к которому нужно стремиться.
Приведенные в документе требования основаны на современном уровне архитектуры Internet.Документ будет обновляться по мере развития спецификаций и технологий в тех областях, с которыми связан этот документ.
Вводная часть документа начинается с краткого обзора архитектуры Internet применительно к хостам, приведены также некоторые рекомендации по выбору программ для хостов.Кроме того, во введении приведены некоторые рекомендации по работе с остальной частью документа и рассмотрена используемая терминология.
1.1 Архитектура Internet
Рассмотрению основ архитектуры Internet и поддерживаемых протоколов посвящена книга DDN Protocol Handbook [INTRO:3], основы архитектуры рассмотрены также в работах [INTRO:9], [INTRO:10], [INTRO:11]. В работе [INTRO:5] рассматриваются вопросы получения документов со стандартами протоколов Internet, а работа [INTRO:6] содержит список номеров (числовых идентификаторов), выделенных для протоколов Internet.
1.1.1 Хосты Internet
Хост-компьютер или попросту хост является конечным пользователем коммуникационного сервиса.На хостах в общем случае выполняются программы по запросам пользователей и/или поддерживаются коммуникационные службы Internet для обслуживания пользовательских запросов.Хосты Internet соответствуют концепции конечной системы (End-System) в стеке протоколов OSI [INTRO: 13].
Коммуникационная система Internet содержит соединенные между собой сети передачи пакетов, в которых обмен информацией между хостами осуществляется на основе протоколов Internet.Сети подключаются к Internet или промежуточным системам OSI (Intermediate Systems, [INTRO: 13]) с использованием компьютеров, обеспечивающих коммутацию пакетов - такие компьютеры называют шлюзами (gateway) или маршрутизаторами IP (IP router)3.В документе Requirements for Internet Gateways
|
||
|
|
||
|
1 На сайте rfc.com.ru можно найти перевод этого документа на русский язык. Прим. перев.
2 Более современный вариант этого документа содержится в RFC-1812. Прим. перев.
3 Во время подготовки этого документа термин gateway (шлюз) использовлся применительно к хостам, обеспечивающим пересылку пакетов между физическими сетями.Со временем функции пересылки трафика стали реализоваться в основном на специализированных устройствах, называемых маршрутизаторами (router), а термин шлюз сейчас относят в основном к системам, обеспечивающим преобразования форматов на более высоких, нежели IP, уровнях (например, шлюз электронной почты).В этом документе мы будем использовать термины “шлюз” и “маршрутизатор” как синонимы, если в тексте явно не будет означено иное. Прим. перев.
Перевод на русский язык - Н. Малых 4 rfc.com.ru
|
||
|
|
||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||||
|
|
||||
|
[INTRO:2] содержатся официальные спецификации для шлюзов (маршрутизаторов) Internet.RFC-10092 вместе с настоящим документом и RFC-1123 [INTRO:1] определяют правила для текущей реализации архитектуры Internet.
Хосты Internet сильно различаются по своим размерам, производительности и выполняемым функциям.В Сети используются самые разные компьютеры, включая настольные ПК, рабочие станции, мэйнфреймы и суперкомпьютеры.По выполняемым функциям хосты делятся на хосты общего назначения (например, терминальные серверы) и мультисервисные (поддержка широкого спектра сетевых служб - remote login, FTP, электронннная почта и т. п.).
Для обозначения хостов с множеством интерфейсов в одну или несколько сетей используется термин multihomed (многодомный). Более подробное описание таких хостов приведено в параграфе 1.1.3 Терминология.
1.1.2 Архитектурные допущения
Современная архитектура Internet основана на группе базовых допущений о коммуникационной системе. Допущения, связанные с хостами, перечислены ниже:
(a) Internet является “сетью сетей”.
Каждый хост напрямую подключен к какой-либо сети (сетям) - соединение с Internet является лишь концептуальным. Два хоста одной сети могут обмениваться между собой данными с использованием тех же протоколов, которые служат для связи с хостами удаленных сетей.
(b) Шлюзы не хранят информацию о состоянии соединений.
Для повышения устойчивости коммуникационных систем шлюзы разрабатываются таким образом, чтобы обеспечивалась пересылка дейтаграмм IP без организации соединений (stateless) и независимо от других дейтаграмм. В результате для обеспечения устойчивости могут использоваться избыточные (redundant) пути, которые активизируются при возникновении сбоев на основных путях. Вся информация, требуемая для сквозного управления потоком данных (end-to-end flow control) через соединение, обеспечивается хостами с помощью программ транспортного или прикладного уровня. Таким образом, все данные для контроля соединения сосредоточены в конечных точках соединения и могут быть потеряны только при сбое на хостах.
(c) Маршрутизация осуществляется в шлюзах.
Маршрутизация является сложным процессом и должна выполняться шлюзами, а не хостами. Важной причиной такого допущения является избавление от необходимости смены или повторной настройки программ в результате изменений, вносимых при сменах архитектуры маршрутизации Internet.
(d) Система должна быть совместима с различными вариантами сетей.
Базовой предпосылкой архитектуры Internet является возможность изменения в широких пределах сетевых параметров (например, скорости каналов, задержки, числа теряемых пакетов, изменения порядка доставки пакетов, максимального размера пакетов и т. п.). Другим важным требованием является устойчивость к сбоям в отдельных сетях, шлюзах, хостах и сохранение возможности работы с доступной скоростью. Конечной целью взаимодействия открытых систем (open system interconnection) является обеспечение эффективной работы Internet и полной интероперабельности для всех типов хостов и сетей, соединенных через различные каналы Internet .
В некоторых случаях разработчики преследуют менее амбициозные цели. Например, среды ЛВС обычно менее требовательны к хостам по сравнению с Internet в целом; локальные сети имеют небольшие задержки, теряется только малая часть пакетов и порядок доставки пакетов обычно сохраняется. Некоторые компании в своих реализациях используют решения, приемлемые для ЛВС, но совершенно не подходящие для гетерогенных сред. Обычно такую продукцию преподносятв качестве дешевого решения для локальных сетей. Однако, изолированная ЛВС может перестать быть таковой и при организации взаимодействия с другими сетями и Internet использование таких упрощенных решений с неизбежностью породит проблемы. В конце концов ни пользователь, ни производитель могут оказаться не в состоянии решить проблемы, возникшие в результате использования не полностью соответствующих стандартам оборудования и программ.
Приведенные в документе требования относятся к полнофункциональным хостам Internet, обеспечивающим полную интероперабельность при использовании самых разных путей передачи данных сети Internet.
1.1.3 Стек протоколов Internet
Для связи через Internet на хостах должен использоваться многоуровневый набор протоколов, соответствующий стеку протоколов Internet.Обычно на хостах реализован по крайней мере один протокол для каждого из уровней.
Уровни протоколов, используемые в архитектуре Internet, описаны в работе [INTRO:4]:
♦ Прикладной уровень (Application Layer)
Прикладной уровень располагается в верхней части стека протоколов Internet.В стеке Internet
прикладной уровень не разделен на подуровни, хотя некоторые из протоколов прикладного уровня
Internet содержат внутренние подуровни.Прикладной уровень стека Internet объединяет в себе
функции двух уровней (Presentation - уровень представления и Application - прикладной) эталонной
модели OSI.
Мы будем различать две категории протоколов прикладного уровня - пользовательские протоколы,
которые предоставляют услуги непосредственно пользователю, и протоколы поддержки,
обеспечивающие системные функции общего назначения.Требования к пользовательским и служебным
протоколам рассмотрены в RFC-1123 [INTRO:1].
Наиболее распространенными пользовательскими протоколами Internet являются:
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
5
|
|||
|
|
||||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
♦ Telnet (удаленный вход в систему)
♦ FTP (передача файлов)
♦ SMTP (доставка электронной почты)
Существует также множество стандартизованных [INTRO:4] и частных пользовательских протоколов. Служебные протоколы используются для преобразования имен, загрузки и управления - к числу таких протоколов относятся SNMP, BOOTP, RARP, DNS (Domain Name System).
♦ Транспортный уровень (Transport Layer) Транспортный уровень обеспечивает сквозную связь (end-to-end) между приложениями через сеть.На транспортном уровне используются два основных протокола:
♦ Transmission Control Protocol (TCP) - протокол управления передачей
♦ User Datagram Protocol (UDP) - протокол пользовательских дейтаграмм
TCP представляет собой основанный на соединениях (connection-oriented) транспортный сервис с
гарантированной доставкой пакетов, обеспечивающий надежную доставку с сохранением порядка
пакетов и управлением потоком данных.Протокол UDP не использует соединений (connectionless) и
передает данные в виде дейтаграмм (datagram) без гарантии доставки.
Исследовательскими организациями были разработаны и другие протоколы транспортного уровня,
которые могут получить статус стандартных протоколов.
Более подробное описание протоколов транспортного уровня приведено в главе 4.
♦ Уровень Internet (Internet Layer) Все транспортные протоколы используют протокол IP (Internet Protocol) для передачи данных от отправителя к получателю.IP представляет собой службу доставки дейтаграмм без организации соединений (connectionless), не обеспечивающую сквозной гарантии доставки.Таким образом при доставке на хост получателя дейтаграммы IP могут оказаться поврежденными; кроме того, не гарантируется порядок их доставки, отдельные дейтаграммы могут быть потеряны, а некоторые -продублированы.Если требуются гарантии доставки, ответственность за такие гарантии должны брать на себя вышележащие уровни.Протокол IP отвечает за адресацию, обозначение типа сервиса, фрагментацию и сборку, а также безопасность.
Передача данных без организации соединений лежит в основе протокола IP и является одной из основных характеристик архитектуры Internet.Протокол IP послужил моделью при разработке сетевого протокола OSI Connectionless Network Protocol [INTRO: 12].
Управляющий протокол ICMP является важной составной частью IP, хотя с точки зрения архитектуры он работает поверх IP (т.е. использует IP для передачи данных, подобно транспортным протоколам TCP и UDP).ICMP обеспечивает доставку сообщений об ошибках, насыщении в сети и перенаправлении для первого маршрутизатора (first-hop).
IGMP представляет собой протокол уровня Internet, используемый для организации динамических групп хостов для группового обмена информацией (IP multicasting). Протоколы уровня Internet (IP, ICMP и IGMP) более подробно рассмотены в главе 3.
♦ Канальный уровень (Link Layer) Для связи с непосредственно подключенными к нему сетями хост должен поддерживать коммуникационный протокол, используемый для обмена данными с сетью.Мы будем называть такой протокол MAC-протоколом (media-access layer protocol) или протоколом канального уровня (link layer). На канальном уровне может использоваться множество протоколов в зависимости от используемой сетевой технологии. Протоколы канального уровня рассмотрены в главе 2.
1.1.4 Встроенная маршрутизация
Программы некоторых хостов Internet включают встроенный маршрутизатор - такие хосты могут пересылать пакеты, как это делают шлюзы, обеспечивая в то же время функции прикладного уровня как обычные хосты.
Такие системы двойного назначения должны соответствовать требованиям RFC-1009 [INTRO:2]4 в части функций шлюза и требованиям настоящего документа, применительно к функциям хоста.Во всех перекрывающихся случаях эти две спецификации должны быть согласованы.
В сообществе Internet существует множество мнений о поддержке встроенных функций маршрутизации. Ниже приведены основные аргументы за и против таких систем5:
♦ За: такие системы могут быть приемлемы с точки зрения удобства и экономичности в локальных сетях или изолированных системах для использования существующих хостов в качестве маршрутизаторов. Существуют также аргументы в пользу встроенной маршрутизации с точки зрения архитектуры -компьютеров с несколькими сетевыми интерфесами больше, нежели с одним интерфейсом и поддержка функций маршрутизации позволяет более эффективно использовать такие хосты.
♦ Против: алгоритмы и протоколы маршрутизации постоянно изменяются с ростом Internet.Попытка реализации этих протоколов на хостах общего назначения будет требовать постоянного обновления программ на таких хостах.Наличие многочисленных реализаций кода маршрутизации дополнительно затрудняет внесение требуемых изменений.И, наконец, реализация уровня IP для шлюза сложнее, нежели для обычного хоста, что делает работу с такими хостами также более сложной. Кроме того, стиль работы некоторых хостов просто неприемлем для их использования в качестве стабильных и надежных маршрутизаторов.
4 Более современный вариант этого документа содержится в RFC-1812. Прим. перев.
5 В современной среде настольных ПК этот вопрос несколько утратил остроту, поскольку функции маршрутизации реализованы практически для всех операционных систем (встроенными средствами или с помощью дополнительных программ). Прим. перев.
Перевод на русский язык - Н. Малых 6 rfc.com.ru
|
||
|
|
||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
Обе точки зрения имеют свои плюсы и минусы.Прежде, чем выбрать решение для себя, администратор должен принять во внимание необходимость поддержки хостом функций маршрутизации.Более детальное рассмотрение этого вопроса приведено в параграфе 3.1.
1.2 Общие вопросы
Существуют два важнейших аспекта, которые должны принимать во внимание разработчики программ для хостов Internet.
1.2.1 Постоянное изменение Internet
Непредсказуемо быстрый рост Internet порождает проблемы управления и масштабирования в гигантских системах передачи дейтаграмм.В результате решения таких проблем изменяются и спецификации, описываемые в данном документе.Изменения планируются и осуществляются под контролем с участием производителей сетевой продукции и организаций, ответственных за работу сетей.
Обновление и постоянное совершенствование являются неотъемлемыми чертами современных сетевых протоколов, хотя еще несколько лет назад такую ситуацию было трудно представить.Разработчики коммуникационных программ для стека протоколов Internet (или иных протоколов) должны поддерживать и обновлять свои программы с учетом изменяющихся спецификаций для того, чтобы не оставить в беде несчастных пользователей.Internet представляет собой большую коммуникационную сеть и пользователи постоянно контактируют с этой сетью.Опыт и знания разработчиков, реализованные в их программах, за короткое время становятся достоянием технического сообщества Internet.
1.2.2 Принципы устойчивости
Для протоколов всех уровней существует общее правило, которому приложения должны следовать во избежание проблем с устойчивостью и интероперабельностью [IP:1]: "будьте либеральны при приеме данных и консервативны при их передаче"
Программы должны уметь обрабатывать все мыслимые ошибки; не имеет значения вероятность возникновения той или иной ошибки - раньше или позже пакет с любой возможной комбинацией ошибок и/или атрибутов будет получен и программа должна быть готова к обработке такого пакета.Если программа не может эффективно обрабатывать ошибки, она приведет прямой дорогой к хаосу.В общем случае лучше предположить, что сеть наводнена зловредными объектами, которые постоянно передают пакеты, предназначенные для наненсения максимального вреда. Такое предположение обеспечит высокий уровень защиты.Наиболее серьезные проблемы в Internet связаны с неисследованными механизмами, включающимися с малой вероятностью; намерения обычных злоумышленников никогда не могут принести такого вреда!
На всех уровнях программ хостов Internet должны быть реализованы средства адаптации.В качестве простого примера рассмотрим спецификацию протокола, использующего численные значения для какого-либо поля в заголовке (например, тип, номер порта или код ошибки) - при разработке следует предполагать, что используемая нумерация неполна.Если спецификация протокола предполагает четыре возможных кода ошибки, приложение должно уметь обрабатывать по крайней мере пять типов ошибок (4 заданных и все остальные).Появление не определенных в спецификации кодов должно протоколироваться (см. ниже), но не должно нарушать работу системы.
Почти так же важен и другой аспект - программы на других хостах могут содержать определения, которые могут толкнуть хост на неразумные, но допустимые с точки зрения протокола действия. Естественным решением будет “поиск неразумных хостов” - программы хоста должны быть готовы не просто переносить появление неразумных хостов, но и участвовать в процессе ограничения вредных воздействий, которые подобные хосты могут нанести сетевым объектам общего пользования.
1.2.3 Протоколирование ошибок
Сеть Internet включает огромное количество разнотипных хостов и шлюзов, в каждом из которых реализовано множество протоколов и уровней - некоторые из хостов и маршрутизаторов наверняка содержат ошибки в программах стека протоколов Internet.В результате сложности, разнотипности и использования распределенных функций диагностика Internet является весьма непростой задачей.
Упростить поиск проблем помогает использование хостами специальных средств протоколирования ошибок и странностей в поведении протоколов.При записи таких событий важно включать макимум диагностической информации.Часто бывает весьма полезно записывать заголовки пакетов, вызывающих ошибки.Однако следует знать меру - средства протоколирования ошибок не должны отнимать слишком много ресурсов хоста и снижать эффективность его работы.
При записи информации об ошибках существует вероятность получения журнальных файлов огромного размера - таких ситуаций можно избежать, используя “циклический” журнал или включая запись только для диагностики определенных сбоев.Полезно также фильтровать и считать повторяющиеся последовательные сообщения. Представляется привлекательной приведенная ниже стратегия:
(1) всегда считать аномальные события и делать содержимое счетчиков доступным с помощью средств управления сетью (см. [INTRO:1]);
(2) поддерживать возможность выбора протоколируемых событий (например, записывать все ошибки, связанные с хостом X).
Отметим, что разные системы управления сетью могут придерживаться различных правил в части числа протоколируемых ошибок для каждого хоста.Некоторые системы исходят из принципа: “если это не имеет ко мне прямого отношения, я не хочу об этом знать", тогда как другие системы прилагают максимум усилий для обнаружения и устранения аномалий в поведении сетевых протоколов.
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
7
|
|||
|
|
||||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989 1.2.4 Конфигурационные параметры
Идеальной реализацией хоста будет та, на которой настройка стека протоколов Internet будет полностью автоматизирована (self-configuring).Это позволит реализовать весь стек в ПЗУ или встроить в микросхемы оборудования - такое решение упростит организацию бездисковых станций, снимет значительную часть нагрузки с сетевых администраторов и упростит разработку систем.Однако этот идеал недостижим и на практике к нему не удается даже серьезно приблизиться.
В этом документе вы будете часто встречать требования, параметры которых являются опциями настройки.Существует несколько причин появления таких требований. В некоторых случаях это обусловлено отстутсвием согласия по вопросу выбора наилучшего значения и в будущем может потребоваться установка иного значения параметра.В других случаях значение параметра может зависеть от внешних факторов (например, скорость и топология соседних сетей) и алгоритмы автоматической настройки могут отсутствовать или не обеспечивать полной настройки параметров.Причиной использования таких параметров могут послужить и административные требования.
Наконец, часть конфигурационных опций может потребоваться для обеспечения взаимодействия с устаревшими или содержащими ошибки реализациями протоколов, распространяемыми без исходных текстов (к несчастью, такое встречается в Internet достаточно часто).Для обеспечения корректного сосуществования с такими “сбойными” системами администраторам зачастую приходится “расстраивать” (mis-configure) корректно работающие системы.Такие проблемы будут решаться сами собой по мере удаления сбойных систем, но разработчики не должны оставлять этот вопрос без внимания.
Когда мы говорим, что параметр требует настройки, это не означает требования читать значение параметра из конфигурационного файла при каждой загрузке.Мы рекомендуем разработчикам устанавливать для таких параметров используемые по умолчанию значения - тогда в конфигурационных файлах могут содержаться лишь те значения, которые не совпадают с принятыми по умолчанию.Таким образом, конфигурационные требования обеспечивают гарантию возможности изменения принятых по умолчанию значений параметров - это решение можно использовать даже при загрузке программного кода из ПЗУ.
В этом документе для ряда случаев указаны значения, которые следует использовать по умолчанию.Выбор принятых по умолчанию значений является достаточно важным вопросом для случаев использования вместе с существующими сбойными системами.По мере продвижения Internet к полной интероперабельности, принятые по умолчанию значения будут реализовать официальный протокол, а не “ расстраивать” систему для обеспечения совместимости с плохо работающими реализациями.Хотя рынок заставляет некоторых производителей устанавливать по умолчанию значения для “расстройки”, мы рекомендуем использовать по умолчанию значения, соответствующие стандартам.
В заключении отметим, что производители продукции должны предоставлять полную документацию по всем конфигурационным параметрам, указывая допустимые значения и описывая влияние параметров на работу системы.
1.3 Работа с документом
1.3.1 Структура документа
Деление протоколов на уровни, которое в общем случае используется как организационный принцип при реализации сетевых программ, служит также принципом организации данного документа.При описании правил мы предполагаем, что реализация достаточно точно отражает деление протоколов по уровням. Таким образом, документ поделен на три основных части - канальный уровень, уровень internet и транспортный уровень.Документ RFC-1123 [INTRO:1] содержит описание программ прикладного уровня. Такая организация документов представляется простой и наглядной.
Однако, жесткое деление на уровни не является совершенной моделью как для стека протоколов, так и для реализации программ.Протоколы различных уровней взаимодействуют в комплексе, иногда даже трудно отделить один протокол от другого, а отдельные функции могут включать несколько уровней.При разработке программных реализаций существует масса вариантов, многие из которых “творчески” подходят к вопросам деления на уровни.Мы рекомендуем всем разработчикам внимательно прочесть документы [INTRO:7] и [INTRO:8].
В этом документе описывается концептуальный интерфейс взаимодействия между уровнями, использующий функциональную нотацию (procedure call - вызов процедур), подобую той, что используется в спецификации TCP [TCP:1].Реализация хоста должна поддерживать логические потоки информации, применяемые при такие вызовах, но не требовать дословной реализации самих вызовов. Например, во многих реализациях связь между транспортным уровнем и IP отражается предоставлением разделяемого доступа к общим структурам данных.
В общем случае все главы документа организованы в форме следующих параграфов:
(1)Введение
(2) Общие вопросы - рассматриваются документы со спецификациями протокола, приводятся исправления ошибок, перечисляются требования, которые могли быть нечетко или неточно сформулированы и приводятся дополнительные комментарии и разъяснения.
(3) Частные вопросы - рассматривается устройство протокола и вопросы реализации, не включенные в предыдущий раздел.
(4) Интерфейсы - обсуждаются услуги, предоставляемые вышележащему протоколу.
(5) Заключение - резюмируются требования данной главы.
Во многих темах документа встречаются параграфы, помеченные как "Обсуждение" или "Реализация".
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
8
|
|||
|
|
||||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
Этот материал предназначен для разъяснения требований, рассмотренных ранее в документе.Такие параграфы также включают некоторые предложения по вариантам будущих разработок.Материалы о реализации содержат предложения, которые могут быть интересны для разработчиков.
Заключение служит в качестве краткого руководства и справочника к главе, но оно слишком кратко для использования в качестве информационного источника.Такие заключения никогда не должны использоваться отдельно от текста полного RFC.
1.3.2 Требования
В этом документе модальные глаголы, служащие для формулировки требований, выделены жирным шрифтом и используются в оговоренном ниже смысле:
Требуется, должен (MUST)
Этот глагол (или причастие от него) используется для обозначения абсолютной необходимости.
Следует, рекомендуется (SHOULD)
Этот глагол (или причастие рекомендуемый) служит для обозначения тех случаев, когда могут существовать дополнительные факторы, позволяющие игнорировать данное требование; в таких случаях рекомендуется принимать взвешенное решение с учетом всех факторов.
Можно (MAY)
Этот глагол и прилагательное необязательный означает, что вопрос реализации требования отдается на откуп разработчику.Кто-то может реализовать требование с целью расширения возможностей, а другой разработчик может отказаться от реализации в целях упрощения.
Реализация считается несовместимой со стандартами, если в ней не выполнены обязательные требования (MUST).Реализация, в которой выполнены все требования MUST и SHOULD считается “безусловно совместимой” (unconditionally compliant); если же выполняются все требования MUST, но проигнорирована часть требований SHOULD. Реализация считается “условно совместимой” (conditionally compliant).
1.3.3 Терминология
Ряд используемых в документе технических терминов определен в данном параграфе.
Сегмент - Segment
Сегментом будем называть модуль6 (unit) данных, используемый для сквозной передачи по протоколу TCP.Сегмент состоит из заголовка TCP, за которым следуют данные.Сегменты передаются с использованием инкапсуляции в дейтаграммы IP.
Сообщение - Message
При описании протоколов нижних уровней термин сообщение обозначает модуль (unit), передаваемый на транспортном уровне.В частности, сегмент TCP является сообщением.Сообщение содержит заголовок транспортного уровня, за которым следуют данные.Для сквозной передачи через сеть Internet сообщение должно инкапсулироваться в дейтаграммы.
Дейтаграмма IP - IP Datagram
Дейтаграмма IP представляет собой модуль данных протокола IP.Дейтаграмма IP содержит заголовок IP, за которым следует информация транспортного уровня (т. е. сообщение).
При описании уровня Internet (глава 3) термин дейтаграмма обычно относится к дейтаграммам IP.
Пакет - Packet
Пакет представляет собой модуль данных, передаваемый через интерфейс между уровнем Internet и канальным уровнем.Пакет включает заголовок IP и данные.Пакет может быть полной дейтаграммой IP или фрагментом такой дейтаграммы.
Кадр - Frame
Кадр представляет собой модуль данных для передачи на канальном уровне и содержит заголовок канального уровня, за которым следует пакет.
Подключенная сеть - Connected Network
Сеть, к которой непосредственно подключен хост, часто называют локальной сетью (local network) или подсетью (subnetwork) применительно к данному хосту.Однако использование этих терминов может привести к путанице, поэтому мы будем пользоваться термином подключенная сеть (connected network).
Multihomed
Хост называют многодомным (multihomed) если он имеет более одного адреса IP.Более подробное обсуждение таких хостов вы найдете в параграфе 3.3.4.
Физический интерфейс - Physical network interface
Физический интерфейс используется для подключения хоста к сети.Интерфейс имеет адрес канального уровня (возможно, уникальный).В хосте может использоваться множество физических интерфейсов с общим адресом канального уровня, но для каждого хоста одной физической сети должен обеспечиваться уникальный адрес на канальном уровне.
Логический интерфейс - Logical [network] interface
Определим логический [сетевой] интерфейс как логический путь в подключенную сеть.Для идентификации логического интерфейса служит уникальный адрес IP.Более подробное рассмотрение логических интерфейсов приведено в параграфе 3.3.4.
6 Термином модуль будем обозначать неделимую при передаче на данном уровне совокупность данных. Прим. перев. Перевод на русский язык - Н. Малых 9 rfc.com.ru
|
||
|
|
||
|
|
||||||||||||||||||||||||||||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
Specific-destination address
Эффективный адрес получателя дейтаграммы, даже если она является широковещательной (broadcast) или групповой (multicast).Дополнительная информация по этому вопросу содержится в параграфе 3.2.1.3.
Путь - Path
В каждый момент времени все дейтаграммы IP от определенного хоста-отправителя к определенному хосту-получателю обычно передаются через одинаковую последовательность маршрутизаторов.Мы будем использовать термин “путь” для обозначения таких последовательностей маршрутизаторов. Отметим, что путь является однонаправленным, т.е.данные между парой хостов могут передаваться в каждом направлении по своему пути.
MTU
Максимальный размер передаваемого модуля данных (т.е.размер наибольшего пакета, который может быть передан через сеть).
Термины кадр, пакет, дейтаграмма и сегмент дополнительно проиллюстрированы на приведенных ниже рисунках.
A. Передача в подключенную сеть:
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
<----------------------------------------Кадр------------------------------->
<------------------------Пакет------------------------>
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
B. Перед фрагментацией IP или после сборки:
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
Заголовок IP
|
Заголовок
|
Данные приложений
|
||||||||||||||||||||||||||||
|
транспорт.
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
уровня
<-----------------------------------Дейтаграмма---------------------->
<-------------------Сообщение--------------------->
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
то же самое для TCP:
_______________
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
Заголовок IP
|
Заголовок TCP
|
Данные приложений
|
||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
< ----------------------------------- Дейтаграмма ----------------------- >
< ----------------------- Сегмент ----------------------- >
1.4 Благодарности
Этот документ включает результаты работы и комментарии большой группы специалистов по протоколам Internet, включая представителей университетов и исследовательских лабораторий, компаний-производителей и государственных агентств.Подготовка документа велась в рабочей группе IETF Host Requirements.
Редактор выражает особую благодарность за неустанную работу людям, принявшим участие в долгих конференциях и написавшим 3 мегабайта почтовых сообщений за 18 месяцев подготовки этого документа, - это: Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU) и James Van Bokkelen (FTP Software).
Кроме того, выражается благодарность всем, кто внес большой вклад в подготовку документа: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), Mike StJohns (DCA).Перечисленные ниже люди внесли значительный вклад в подготовку отдельных тем: Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco) и Rayan Zachariassen (Toronto).
Благодарим также всех, кто так или иначе способствовал появлению этого документа.
2. Канальный уровень 2.1 Введение
Для всех систем Internet - хостов и маршрутизаторов - предъявляются одинаковые требования к протоколам канального уровня.Эти требования подробно рассмотрены в главе 3 документа "Requirements for Internet Gateways" [INTRO:2] и дополнены в настоящем документе.
|
||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
Перевод на русский язык - Н. Малых
|
10
|
|||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
2.2 Общие вопросы
Не рассматриваются.
2.3 Частные вопросы
2.3.1 Согласование трейлерного протокола
Для инкапсуляции на канальном уровне может использоваться трейлерный протокол (trailer protocol) [LINK:1], но использование такого протокола должно быть согласовано обеими системами (хосты или маршрутизаторы), взаимодействующими на канальном уровне с применением трейлеров.Если системы не могут согласовать трейлерный протокол динамически (для каждого получателя), принятая по умолчанию конфигурация должна запрещать использование трейлеров.
Обсуждение:
Трейлерный протокол представляет собой метод инкапсуляции на канальном уровне, обеспечивающий перекомпоновку (rearrange) пакетов, передаваемых в физическую сеть.В некотрых случаях трейлеры повышают производительность протоколов верхних уровней за счет снижения объема копируемых данных. Протоколы верхних уровней не знают об использовании трейлеров, но приемник и передатчик пакетов должны понимать, какой протокол используется для инкапсуляции.
Некорректное использование трейлеров может привести к серьезной путанице.С использованием трейлеров инкапсулируются только пакеты с заданным набором атрибутов и обычно этому требованию удовлетворяет лишь малая часть передаваемых пакетов.Таким образом, если одна система будет использовать трейлеры, а другая не будет, часть пакетов будет “улетать в черную дыру”, а остальные будут доставляться нормально.
Реализация
В сетях Ethernet пакеты, инкапсулируемые с трейлерами, используют различные типы Ethernet [LINK:1] и согласование трейлера выполняется одновременно с использованием ARP для определения адреса получателя.Обмен пакетами ARP для определения адреса осуществляется обычным способом, но хост, согласующий трейлер, будет передавать дополнительный отклик ARP (trailer ARP reply), указывающий тип трейлерного протокола инкапсуляции в формате обычного отклика ARP.Если хост, настроенный на использование трейлеров, получает отклик ARP с типом трейлера от удаленной машины, он может добавить ее в список систем, поддерживающих трейлеры (например, пометив соответствующую запись в кэше ARP).
Хосты, желающие использовать трейлерную инкапсуляцию передают отклик trailer ARP всякий раз при завершении нормального обмена ARP для IP-адреса.Таким образом, хост, получивший запрос ARP для своего IP-адреса, будет передавать отклик trailer ARP в дополнение к нормальному отклику IP ARP; хост, передавший запрос IP ARP, будет передавать отклик trailer ARP при получении отклика на запрос IP ARP.При таком способе как запрашивающий, так и отвечающий хост в процессе обмена пакетами IP ARP может запросить использование трейлерной инкапсуляции.
Такая схема с использованием дополнительных пакетов trailer ARP reply вместо запросов ARP на указание типа трейлерного протокола была разработана для того, чтобы избежать непрерывного обмена пакетами ARP с некорректно работающими хостами, которые в ответ на запрос типа трейлера передают стандартный отклик ARP для IP-адреса.Проблема решается за счет передачи отклика trailer ARP в ответ на отклик IP ARP только в тех случаях, когда отклик IP ARP отвечает на невыполненный запрос (это верно для тех случаев, когда аппаратный адрес хоста остается неизвестным к моменту получения отклика IP ARP).Отклик trailer ARP всегда можно посылать вместе с откликом IP ARP, соответствующим запросу IP ARP.
2.3.2 Протокол преобразования адресов - ARP
2.3.2.1 Проверка кэша ARP
Реализация протокола преобразования адресов ARP (Address Resolution Protocol) [LINK:2] должна обеспечивать механизм удаления устаревших записей из таблицы.Если поддерживаемый механизм использует тайм-аут, должна обеспечиваться возможность настройки времени ожидания.
Реализация должна обеспечивать механизм предотвращения лавинной рассылки (ARP flooding) в виде повторяющихся с высокой частотой запросов ARP Request для одного адреса IP.Рекомендуемая частота запросов не должна превышать для каждого адреса 1 запрос/сек.
Обсуждение:
Спецификация ARP [LINK:2] предлагает, но не требует использовать механизм тайм-аутов для объявления некорректными (invalidate) элементов кэша при смене хостом своего адреса Ethernet. Широкое распространение proxy ARP (см.параграф 2.4 в работе [INTRO:2]) существенно повышает вероятность того, что в кэше будут содержаться некорректные записи, следовательно требуется механизм удаления устаревших записей из кэша ARP.Даже в отсутствие proxy ARP использование тайм-аутов полезно для автоматической корректции данных ARP, которые могли быть кэшированы.
Реализация
Для удаления устаревших записей из кэша используется 4 механизма (иногда в комбинации).
(1) Timeout - записи периодически удаляются из кэша, даже если они остаются актуальными7.При
7 Отсчет времени должен начинаться заново всякий раз, когда запись в кэше обновляется (refresh).Точка отсчета определяется путем просмотра полей отправителя независимо от искомого (target) адреса в широковещательных
Перевод на русский язык - Н. Малых 11 rfc.com.ru
|
||
|
|
||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
использовании ARP тайм-аут должен быть порядка 1 минуты.
(2) Unicast Poll - активный опрос (poll) удаленных хостов с помощью периодической отправки по их адресам пакетов ARP Request и удаление записей для тех адресов, от которых не пришло пакетов ARP Reply после N последовательных опросов.Тайм-аут должен по прежнему составлять около 1 минуты, а типичное значение N = 2.
(3) Link-Layer Advice - если драйвер канального уровня обнаруживает проблемы с доставкой, соответствующая запись удаляется из кэша ARP.
(4) Higher-layer Advice - обеспечивается вызов на канальный уровень с уровня Internet для индикации проблем с доставкой.Эффект такого вызова заключается в том, что соответствующая запись удаляется из кэша.Такой вызов является аналогом вызова ADVISE_DELIVPROB() с транспортного уровня на уровень Internet (см.параграф 3.4) и подрограмма ADVISE_DELIVPROB фактически может использоваться для вызова программы канального уровня, удаляющей запись из кэша ARP.
Варианты (1) и (2) используют тайм-аут порядка 1 минуты или меньше.При отсутствии ARP такой короткий период ожидания может породить заметный избыточный трафик в больших сетях Ethernet. Следовательно, может потребоваться увеличение тайм-аута ARP.
2.3.2.2 Очередь пакетов ARP
Канальный уровень должен сохранять (а не отбрасывать) по крайней мере один (последний) пакет из каждой группы пакетов для того или иного адреса IP и передавать сохраненный пакет, когда адрес будет преобразован (resolve).
Обсуждение:
Невыполнение приведенного выше требования приводит к потере первого пакета при каждом обмене. Хотя протоколы верхних уровней в общем случае способны заново отправлять пакеты при их потере, утрата пакетов будет снижать производительность системы.Например, потеря запроса на открытие сеанса TCP приведет к тому, что оценка времени обмена (round-trip time) будет некорректной. Приложения на основе UDP (такие, как DNS) будут еще сильнее страдать от такого недостатка.
2.3.3 Инкапсуляция Ethernet и IEEE 802
Инкапсуляция пакетов IP для сетей Ethernet описана в RFC-894 [LINK:3], а RFC-1042 [LINK:4] содержит описание инкапсуляции IP для сетей IEEE 802.RFC-1042 уточняет вопросы, рассмотренные в параграфе 3.4 работы [INTRO:2].
Для каждого хоста Internet, подключенного к сети Ethernet (10 Мбит/с) с помощью кабеля
♦ требуется поддержка приема и передачи пакетов с использованием инкапсуляции RFC-894;
♦ рекомендуется поддерживать прием пакетов RFC-1042 вперемешку с пакетами RFC-894;
♦ можно поддерживать передачу пакетов с использованием инкапсуляции RFC-1042.
Хосты Internet, реализующие передачу с использованием инкапсуляции обоих типов (RFC-894 и RFC-1042), должны поддерживать возможность настройки (конфигурационная опция) используемого типа инкапсуляции. По умолчанию требуется использовать инкапсуляцию RFC-894.
Отметим, что стандартная инкапсуляция IP в соответствии с RFC-1042 не использует значение идентификатора протокола (K1=6), которое зарезервировано IEEE для протокола IP, устанавливая вместо этого значеник K1 = 170, указывающще на расширение (SNAP), которое может использоваться для поля Ether-Type.
Системы Internet не должны передавать пакетов IEEE 802 с использованием K1=6.
Трансляция адресов Internet в адреса канального уровня для сетей Ethernet и IEEE 802 должна обеспечиваться на основе протокола ARP.
Значение MTU для Ethernet составляет 1500, а для 802.3 - 1492 байта.
Обсуждение:
Спецификация IEEE 802.3 обеспечивает работу по кабелям Ethernet 10 Мбит/с, что может вести к смешению в одной физической среде кадров Ethernet и IEEE 802.3. Приемник может различать кадры Ethernet и 802.3 по значению поля длины (Length ) для 802.3 - это 2-октетное поле совпадает8с полем Ether-Type в кадрах Ethernet.Значение поля длины для кадров 802.3 не должно превышать 1500, а все корректные значения Ether-Type превышают 1500.
Другая проблема совместимости связана с широковещательными кадрами на канальном уровне. Широковещательные кадры одного типа не будут видны хостам, способным принимать лишь другой тип кадров.
Основной задачей данного параграфа является обеспечение рекомендаций по интероперабельности сетей с инкапсуляцией RFC-894 и RFC-1042 в одной физической среде.Основной упор делается на сети с использованием RFC-894 с учетом перехода в будущем на инкапсуляцию RFC-1042.
Отметим, что системы, поддерживающие только RFC-894, не могут напрямую взаимодействовать с системами RFC-1042.Если каждый тип инкапсуляции организовать в виде логической сети (на том же кабеле), то две логические сети можно будет связать через шлюз IP (маршрутизатор).Использование хостов, способных поддерживать оба формата, не всегда полезно (и не всегда возможно) поскольку трудно автоматически определить формат передачи кадров из-за проблем с широковещательными
|
||
|
|
||
|
пакетах ARP. 8 По расположению в кадре. Прим. перев.
Перевод на русский язык - Н. Малых 12 rfc.com.ru
|
||
|
|
||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
кадрами канального уровня.
2.4 Интерфейс между канальным уровнем и IP
Интерфейс приема пакетов между IP и канальным уровнем должен включать флаг, показывающий пакеты для широковещательной рассылки на канальном уровне.
Обсуждение
Хотя уровень IP в общем случае не знает адресов канального уровня (поскольку в каждой физической среде используется свой формат адресации), широковещательный адрес для поддерживающих широковещательную рассылку сред представляет является в некотором роде исключением из общего правила. Более подробное рассмотрение этого вопроса приведено в параграфе 3.2.2.
Интерфейс передачи пакетов между IP и канальным уровнем должен включать 5-битовое поле TOS, описанное в параграфе 3.2.1.6.
Канальный уровень не должен передавать сообщения об ошибке Destination Unreachable на уровень IP при отсутствии записи с адресом получателя в кэше ARP.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2.5 Требования к канальному уровню
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
3. Протоколы уровня INTERNET
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
3.1 Введение
Принцип устойчивости - "быть либеральным при приеме и консервативным при передаче" особенно важен для уровня Internet, где некорректное поведение одного хоста может блокировать работу множества других хостов.
К числу протокольных стандартов уровня Internet относятся:
♦ RFC-791 [IP:1] определяет протокол IP и содержит введение в архитектуру Internet.
♦ RFC-792 [IP:2] определяет протокол ICMP, обеспечивающий маршрутизацию, диагностику и сообщения об ошибках для протокола IP.Хотя сообщения ICMP инкапсулируются в дейтаграммы IP, обработка ICMP рассматривается (и обычно реализована) как часть уровня IP. См. параграф 3.2.2.
♦ RFC-950 [IP:3] - определяет обязательную поддержку подсетей для архитектуры адресации.
♦ RFC-11129 [IP:4] определяет протокол IGMP (Internet Group Management Protocol - протокол управления группами Internet) как часть рекомендуемого расширения для хостов и интерфейсов хост-шлюз, обеспечивающего в масштабах Internet поддержку групповой адресации на уровне IP.См. параграф 3.2.3.
Адресатами групповых (multicast) пакетов IP могут быть произвольные группы хостов Internet. Групповая адресация IP разработана как естественное расширение групповой адресации на канальном уровне и обеспечивает стандартное толкование для локального доступа к multicasting-объектам.
Ссылки на другие источники информации приведены в главе 5.
Программы уровня Internet на каждом хосте должны поддерживать оба протокола - IP и ICMP. Требования в части поддержки IGMP рассмотрены в параграфе 3.3.7.
9 В RFC-2236 включены добавления к стандарту RFC-1122 в части протокола IGMP. Прим. перев.
Перевод на русский язык - Н. Малых 13 rfc.com.ru
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
Уровень IP выполняет две основных функции: (1) выбирает следующий маршрутизатор или хост (next hop) для исходящих дейтаграмм IP и (2) обеспечивает сборку принимаемых дейтаграмм IP.Уровень IP также может (3) реализовать преднамеренную фрагментацию исходящих дейтаграмм.Наконец, уровень IP должен (4) поддерживать детектирование и обработку ошибок.Предполагается, что в будущем функциональность уровня IP может быть расширена путем разработки новых приложений Internet для контроля и управления.
Для нормальных дейтаграмм осуществляется прямая (straightforward) обработка.Для исходящих дейтаграмм уровень IP выполняет следующие операции:
(1) проверка корректности форматирования дейтаграммы;
(2) проверка того, что дейтаграмма адресована локальному хосту;
(3) обработка опций;
(4) при необходимости сборка дейтаграмм из фрагментов;
(5) передача инкапсулированного в дейтаграмме сообщения соответствующему модулю транспортного уровня.
Для исходящих дейтаграмм уровень IP выполняет следующие операции:
(1) установка всех полей, не заданных на транспортном уровне;
(2) выбор подходящего интерфейса подключенной сети (маршрутизация - routing);
(3) фрагментация дейтаграммы, если это необходимо, или преднамеренная фрагментация при использовании таковой (см. параграф 3.3.3);
(4) передача пакетов сооьветствующему драйверу канального уровня.
Хост называют многодомным (multihomed), если он имеет несколько адресов IP.Поддержка множества адресов для хостов вносит в стек протоколов дополнительную сложность и возможность путаницы, В этой части архитектуры Internet требуется серьезная работа для решения всех проблем.С поддержкой множества адресов связаны, прежде всего, две аспекта проблемы:
(1) Local multihoming - рассматриваемый хост имеет множество адресов;
(2) Remote multihoming - локальному хосту приходится работать с удаленным хостом, использующим множество адресов.
В настоящее время обслуживание работы с удаленными многодомными хостами должно обеспечиваться на прикладном уровне, как описано в RFC-1123 [INTRO:1].Работа с локальным хостом, поддерживающим множество адресов, рассмотрена ниже (параграф 3.3.4).
Любой хост, пересылающий дейтаграммы от других хостов, действует как маршрутизатор и должен удовлетворять спецификациям маршрутизаторов (шлюзов), рассматриваемым в RFC-100910 [INTRO:2].Хост Internet, поддерживающий встроенный маршрутизатор, должен иметь конфигурационные опции, позволяющие отключить маршрутизацию и по умолчанию маршрутизация должна быть выключена.В таком режиме дейтаграмма, принятая через какой-либо интерфейс, не будет пересылаться другому хосту или шлюзу (если не используется маршрутизация, заданная отправителем - source-route), независимо от числа имеющихся в данном хосте интерфейсов. Не допускается автоматический переход хоста в режим маршрутизатоции при наличии на хосте нескольких интерфейсов, поскольку оператор хоста может не желать выполнять функции маршрутизации и быть некомпетентным в этом вопросе.
В таких случаях для принятой дейтаграммы зачастую используют операцию silently discard (выбросить по-тихому).Это означает, что дейтаграмма отбрасывается без дальнейшей обработки и даже не передается сообщение ICMP об ошибке (см. параграф 3.2.2). Однако, для обеспечения диагностики хост должен обеспечивать возможность протоколирования таких ошибок (см. параграф 1.2.3), включая запись содержимого отбрасываемых дейтаграмм.Кроме того, количество отбрасываемых дейтаграмм должно учитываться счетчиком статистики.
Обсуждение:
Тихое отбрасывание ошибочных дейтаграмм в общем случае используется для предотвращения широковещательных штормов (broadcast storms).
3.2 Общие вопросы
3.2.1 Протокол Internet - IP
3.2.1.1 Номер версии: RFC-791, параграф 3.1 Дейтаграммы с номером версии, отличающимся от 4, должны отбрасываться без уведомления.
3.2.1.2 Контрольная сумма: RFC-791, параграф 3.1
Хост должен проверять контрольную сумму заголовка IP для каждой полученной дейтаграммы и отбрасывать без уведомления дейтаграммы с некорректной контрольной суммой.
3.2.1.3 Адресация: RFC-791, параграф 3.2
Существует пять классов IP-адресов - от A до E.Адреса класса D используются для групповой адресации IP [IP:4], а класс E зарезервирован для экспериментов.
Групповые адреса (класс D) представляют собой 28-битовые логические адреса, используемые для групп хостов, и могут быть постоянными (permanent) или временными (transient).Постоянные групповые адреса
10 Более современный вариант этого документа содержится в RFC-1812. Прим. перев.
Перевод на русский язык - Н. Малых 14 rfc.com.ru
|
||
|
|
||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
распределяет IANA (Internet Assigned Number Authority) [INTRO:6], а временные динамически выделяются для временных групп хостов.Принадлежность к группе определяется динамически на основе протокола IGMP [IP:4].
Рассмотрим более подробно IP-адреса классов A, B и C, используя обозначения:
{ <Номер сети>, <Номер хоста> }
или
{ <Номер сети>, <Номер подсети>, <Номер хоста> }
и "-1" для полей, содержащих только единицы (1).Такая нотация не предполагает, что единицы в маске адреса должны быть непрерывными.
(а) { 0, 0 }
Данный хост в данной сети.Такие адреса не должны передаваться за исключением случаев передачи адреса отправителя в процессе инициализации, посредством которого хост узнает свой IP-адрес.
В параграфе 3.3.6 рассмотрены варианты нестандартного использования {0,0}.
(Ь){ 0, <Номер хоста> }
Указывает хост данной сети.Такие адреса не должны передаваться за исключением случаев использования как адреса отправителя в процедурах инициализации, с помощью которых хост получает полный IP-адрес.
(с) { -1, -1 }
Широковещательный пакет ограниченного действия (Limited broadcast).Такой адрес не должен устанавливаться в поле отправителя.
Дейтаграмма с таким адресом получателя будет приниматься каждым хостом данной физической сети, но не будет проходить за пределы сети через маршрутизаторы.
(d){ <Номер сети>, -1 }
Широковещательный адрес для данной сети.Такой адрес не должен устанавливаться в поле отправителя.
(e) { <Номер сети>, <Номер подсети>, -1 }
Широковещательный пакет для указанного маршрутизатора (конкретной подсети).Такой адрес не должен устанавливаться в поле отправителя.
(f) { <Номер сети>, -1, -1 }
Широковещательный пакет для всех подсетей данной сети. Такой адрес не должен устанавливаться в поле отправителя.
(д){ 127, <любой> }
Внутренний loopback-адрес хоста. Такой адрес не должен выходить за пределы хоста.
Номера сетей распределяются административно, чтобы каждая сеть в масштабе планеты имела уникальный номер.
IP не должен иметь значений 0 и -111 в любом из полей <Номер хоста>, <Номер сети> или <Номер подсети>, за исключением специальных случаев, перечисленных выше.Это требование подразумевает, что каждое из полей должно иметь размер не менее 2 битов.
Более подробное рассмотрение широковещательных адресов дается в параграфе 3.3.6.
Хост должен поддерживать подсети IP [IP:3].В соответствии с этим требованием каждый хост должен иметь маску адреса в форме {-1, -1, 0} (см. параграфы 3.2.2.9 и 3.3.1.1).
Когда хост передает дейтаграмму, в качестве IP-адреса отправителя должен указываться один из IP-адресов этого хоста, но не широковещательный или групповой адрес.
Хост должен отбрасывать без уведомления входящие дейтаграммы, не адресованные этому хосту. Входящая дейтаграмма считается адресованной хосту, если в поле адреса получателя указан:
(1) IP-адрес этого хоста (один из имеющихся);
(2) широковещательный адрес IP, корректный для данной сети;
(3) адрес multicast-группы12, в которую входит данный хост.
В большинстве случаев дейтаграммы, адресованные всем (broadcast) или группе (multicast) хостов, обрабатываются так, будто они направлены по одному из IP-адресов данного хоста.Мы будем использовать термин “конкретный адрес получателя” (specific-destination address) в качестве эквивалента локального IP-адреса хоста.Конкретный адрес получателя должен указываться в заголовках пакетов IP, если такие пакеты не являются групповыми или широковещательными.Конкретный адрес получателя является IP-адресом физического интерфейса, через который дейтаграмма принимается хостом.
Хост должен без уведомления отбрасывать дейтаграммы, содержащие адрес отправителя, противоречащий приведенным в этом параграфе правилам.Проверка корректности может осуществляться на уровне IP или любым протоколом транспортного уровня.
Обсуждение:
Дейтаграммы с некорректными адресами могут появляться в результате широковещательной рассылки на канальном уровне дейтаграмм с конкретным (unicast) адресом или вследствие ошибок в настройках хостов и маршрутизаторов.
11 Только единицы (например, 255). Прим. перев.
12 На принимающем физическом интерфейсе. Прим. перев.
Перевод на русский язык - Н. Малых 15 rfc.com.ru
|
||
|
|
||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
Архитектура хостов Internet должна поддерживать обработку IP-адресов как 32-битовых целых чисел без каких-либо особенностей и избегать применения алгоритмов, требующих знания формата IP-адресов.Если этому правилу не следовать, любые изменения формата или интерпретации адресов в будущем потребуют внесения изменений в программы хостов.Однако, проверка корректности широковещательных и групповых адресов требует отказа от таких правил13.
Разработчики программ должны знать, что приложения, использующие широковещательную адресацию во все подсети (рассмотренный выше вариант f) могут оказаться неработоспособными в некоторых сетях.Широковещание для всех подсетей поддерживается не всеми маршрутизаторами и даже при наличии такой поддержки отдельные администраторы запрещают ее при настройке маршрутизаторов.
3.2.1.4 Фрагментация и сборка: RFC-791, параграф 3.2
Модель Internet требует, чтобы каждый хост поддерживал сборку фрагментов (reassembly).Требования к фрагментации и сборке рассмотрены в параграфах 3.3.2 и 3.3.3.
3.2.1.5 Идентификация: RFC-791, параграф 3.2
При передаче идентичной копии ранее отправленной дейтаграммы хост может сохранять
идентификационное поле для такой копии.
Обсуждение:
Некоторые специалисты по протоколам Internet утверждают, что при передаче копии ранее отправленной дейтаграммы эта копия должна содержать такое же значение поля идентификации, как оригинал.Это обеспечивает два преимущества: (1) если дейтаграмма фрагментирована и некоторые фрагменты теряются, принимающая сторона может восстановить полную дейтаграмму из фрагментов оригинала и копии; (2) загруженный (congested) маршрутизатор может использовать поле IP Identification (и поле Fragment Offset - смещение фрагмента) для удаления дубликатов дейтаграмм из очереди.
Однако наблюдения за реальным трафиком и потерей дейтаграмм в Internet показывают, что использование первого из перечисленных преимуществ маловероятно в силу существования других механизмов (например, перепаковка TCP перед повторной передачей), предотвращающих повторную передачу идентичных дейтаграмм [IP:9].Следовательно, сохранение идентиификационного поля при повторной передаче дейтаграмм может оказаться бесполезным.Кроме того, работающие без организации соединения протоколы (типа UDP) будут требовать взаимодействия с прикладными программами для сохранения значения идентификационного поля при повторной передаче .
3.2.1.6 Тип обслуживания: RFC-791, параграф 3.2
Байт Type-of-Service (тип обслуживания) в заголовке IP поделен на 2 части - поле Precedence (3 старших бита) и поле TOS (5 младших битов).В этом документе термин TOS всегда относится к одноименному полю (младшие 5 битов).
Поле Precedence предназначено для специальных приложений Министерства Обороны14 (Department of Defense).Вопросы использования отличных от 0 значений этого поля выходит за пределы компетенции настоящего документа и стандартов IP.Производители продукции должны консультироваться с агентством DCA (Defense Communication Agency) для получения рекомендаций по использованию поля Precedence в своих реализациях протоколов других уровней15.Однако, разработчики должны понимать, что использование поля precedence потребует передачи его значения между протоколами разных уровней, как это делается для поля TOS.
Уровень IP должен обеспечивать для транспортного уровня способ установки поля TOS в каждой передаваемой дейтаграмме (по умолчанию все биты имеют нулевые значения). Рекомендуется для уровня IP передавать значения TOS принятых из сети пакетов на транспортный уровень.
Отображения TOS на канальном уровне, определенные в RFC-795, не рекомендуется применять.
Обсуждение:
Хотя поле TOS мало использовалось в прошлом, планируется возрастание роли этого поля в ближайшем будущем.Предполагается, что TOS будет использоваться для управления двумя аспектами работы шлюзов - маршрутизацией и алгоритмами использования очередей.В параграфе 2 работы [INTRO:1] рассматриваются требования к прикладным программам для работы с полем TOS.
Значение TOS должно также отображаться на селекторы сервиса канального уровня.Такое решение, например, используется для организации эффективного совместного использования (sharing) последовательных каналов разными классами трафика TCP.Однако отображение, предложенное в RFC-795 для сетей, которые входили в состав Internet в 1981 году, сейчас явно устарело.
3.2.1.7 Время жизни: RFC-791, параграф 3.2
Хост не должен передавать дейтаграмм с нулевым значением времени жизни (поле Time-to-Live - TTL).
Хост не должен отбрасывать дейтаграммы лишь потому, что они приняты со значением поля TTL < 2.
Уровень IP должен обеспечивать для транспортного уровня способ установки поля TTL в каждой передаваемой дейтаграмме.При использовании фиксированного значения TTL требуется обеспечить возможность настройки этого значения.Рекомендуемые значения времени жизни указаны в документе
|
||
|
|
||
|
13 Существует еще ряд исключений, рассматриваемых в этом документе.
14 США. Прим. перев.
15 В настоящее время использование поля Precedence оговорено в ряде новых RFC (1812, 2460, 2474, 2873). Прим. перев.
Перевод на русский язык - Н. Малых 16 rfc.com.ru
|
||
|
|
||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
"Assigned Numbers"16.
Обсуждение:
Поле TTL обеспечивает две функции - ограничение времени жизни сегментов TCP (RFC-793 [TCP:1], стр.28) и прерывание (terminate) петель в маршрутизации Internet.Хотя TTL задает время в секундах, это поле иcпользуется также в качестве счетчика интервалов (hop-count), поскольку каждый маршрутизатор должен уменьшать значение поля TTL на 1.
Смысл поля TTL состоит в том, что при уменьшении значения этого поля до 0 дейтаграмма отбрасывается маршрутизатором (но не конечным хостом).Хосты, выполняющие функции маршрутизации, должны следовать этому правилу для TTL, как маршрутизаторы.
Протокол вышележащего уровня может устанавливать значение TTL при реализации поиска в расширенной области ("expanding scope" search) для некоторых ресурсов Internet.Такой ход используется также некоторыми средствами диагностики и может оказаться полезным в целом ряде случаев (например, для обнаружения “ближайшего” сервера данного класса, использующего IP multicasting).Конкретный протокол транспортного уровня может задать свою границу TTL для максимального времени жизни дейтаграмм.
При использовании фиксированного значения времени жизни оно должно быть достаточно велико (по крайней мере, больше “диаметра” Internet, т.е.самого длинного из возможных путей).Разумно устанавливать для времени жизни двойной “диаметр” с учетом продолжающегося расширения Internet.
3.2.1.8 Опции: RFC-791, параграф 3.2
Для транспортного уровня должен обеспечиваться способ задания опций IP для включения во все передаваемые дейтаграммы IP (см. параграф 3.4).
Все опции IP (за исключением NOP и END-OF-LIST) из принимаемых дейтаграмм должны пердаваться на транспортный уровень или системе обработки ICMP (если дейтаграмма является сообщением ICMP).Оба уровня (транспортный и уровень IP) должны интерпретировать понятные им опции IP, игнорируя остальные.
Ниже в этом документе рассматриваются вопросы поддержки специфических опций IP, требуемой протоколами ICMP, TCP и UDP.
Обсуждение:
Передача всех принятых опций IP на транспортный уровень является преднамеренным “нарушением жесткого деления на уровни,” которое предназначено для упрощения ввода в будущем новых опций IP, относящихся к транспортному уровню.Каждый уровень должен выбрать все имеющие к нему отношение опции для внутренней обработки и игнорировать остальные опции. Для этого каждая опция IP (кроме NOP и END-OF-LIST) указывает свой размер.
В этом документе не определяется порядок обработки опций каждого заголовка IP.Хосты, использующие множество опций при передаче, должны понимать, что результаты могут зависеть от порядка обработки опций.
Реализация
Программы IP-уровня должны быть устойчивы к сообщениям с опциями, размер которых выходит за допустимые пределы.Известны примеры реализаций, которые входят в бесконечный цикл при получении пакетов с полем опций некорректного размера.
Ниже перечислены требования к отдельным опциям IP:
(a) Security (безопасность)
Некоторые среды требуют наличия опции Security в каждой дейтаграмме - такие требования выходят за пределы рассмотрения настоящего документа и стандартов IP.Отметим, что опции безопасности, определенные в RFC-791 и RFC-1038, утратили силу.Для приложений DoD17 разработчикам следует обращаться к документу [IP:8].
(b) Stream Identifier (идентификатор потока)
Эта опция устарела - она не должна передаваться в пакетах а на приемной стороне должна игнорироваться.
(c) Source Route (маршрутизация отправителем)
Хост должен поддерживать маршрутизацию отправителем в исходящих дейтаграммах и должен поддерживать себя, как конечного адресата при маршрутизации отправителем.
Если хост получает дейтаграмму, содержащую завершенный маршрут от отправителя18 (completed source route), это говорит о доставке дейтаграммы конечному адресату.Принятые опции (записанный маршрут) должны передаваться на транспортный уровень (или системе обработки сообщений ICMP). Записанные маршруты будут инвертироваться и использоваться для передачи отклика на дейтаграмму (см.Опции IP в главе 4).Когда маршрут возврата построен, требуется корректно сформировать его даже при использовании записи маршрута от хоста-отправителя (см. пункт (B) ниже).
Заголовки IP, содержащие более одной опции Source Route, не должны передаваться, поскольку маршрутизация в таких случаях будет зависеть от реализации.
|
||
|
|
||
|
16 Последний вариант этого документа находится в RFC-1700. Прим. перев.
17 Министерство обороны США. Прим. перев.
18 т. е. указатель за пределы последнего поля.
Перевод на русский язык - Н. Малых 17 rfc.com.ru
|
||
|
|
||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
В параграфе 3.3.5 приведены правила для хостов, выступающих в качестве промежуточных (intermediate hop) для source route (т.е. пересылающих дейтаграммы с заданной отправителем маршрутизацией).
Обсуждение:
При фрагментировании дейтаграмм source-route каждый фрагмент будет содержать копию заданного отправителем маршрута.Поскольку обработка опций IP (включая source route) должна предшествовать сборке фрагментов, исходная дейтаграмма не может быть сбрана до тех пор, пока она не будет доставлена конечному адресату.
Предположим, что такая дейтаграмма передается от хоста S на хост D через шлюзы G1, G2, ... Gn. В спецификации IP существуют неоднозначности, позволяющие задавать для опций source route дейтаграмм, передаваемых хостом S, вариант (A) или (B):
A) {>>G2, G3, ... Gn, D} <----- корректно
B) {S, >>G2, G3, ... Gn, D} <------- ошибка
(>> представляет указатель).При использовании варианта (A) дейтаграмма, принятая хостом D, будет содержать опции {G1, G2, ... Gn >>}, с IP-адресами хостов S и D как отправителя и получателя. Если использован вариант (B), принятая хостом D дейтаграмма будет по-прежнему содержать адреса S и D как отправителя и получателя, но опции будут иметь вид {S, G1, ...Gn >>}, т. е; хост-отправитель исходной дейтаграммы оказывается первым в маршруте возврата.
(d) Record Route (запись маршрута) Реализация установки и обработки опции Record Route является необязательной.
(e) Timestamp (временная метка) Реализация установки и обработки опции Timestamp является необязательной.При реализации этой опции должны выполняться следующие правила:
♦ Хост-отправитель должен записывать временную метку в поле Timestamp опций, для которых поле адреса еще не указано или содержит адрес интерфейса данного хоста.
♦ Принимающий хост должен (если это возможно) добавить текущее время в опцию Timestamp перед передачей опции для обработки на транспортный уровень или ICMP.
♦ Значение временной метки должно соответствовать требованиям, приведенным в параграфе 3.2.2.8 для сообщений ICMP Timestamp.
3.2.2 Протокол управляющих сообщений Internet - ICMP
Сообщения ICMP делятся на два класса19.
♦ ICMP-сообщения об ошибках: Destination Unreachable - адресат недоступен (см. параграф 3.2.2.1) Redirect - перенаправление (см. параграф 3.2.2.2) Source Quench - “заткнуть рот отправителю” (см. параграф 3.2.2.3) Time Exceeded - время истекло (см. параграф 3.2.2.4) Parameter Problem - проблема с параметрами (см. параграф 3.2.2.5)
♦ Запросы ICMP: Echo - эхо (см. параграф 3.2.2.6) Information - информация (см. параграф 3.2.2.7) Timestamp - временная метка (см. параграф 3.2.2.8) Address Mask - маска адреса (см. параграф 3.2.2.9)
При получении сообщений ICMP неизвестного типа такие сообщения должны отбрасываться без уведомления.
Каждое сообщение ICMP об ошибке включает заголовок Internet и по крайней мере первые 8 октетов дейтагараммы, с которой связана ошибка.Заголовок и данные должны в точности соответствовать исходной дейтаграмме, связанной с ошибкой; возможно включение более 8 октетов.
В тех случаях, когда уровень Internet должен передавать сообщения ICMP на транспортный уровень, из исходного сообщения должен извлекаться номер протокола IP, используемый для выбора соответствующего объекта транспортного уровня, обеспечивающего обработку ошибок.
Сообщения ICMP об ошибках должны передаваться с нормальными (т. е., 0) значениями битов TOS.
Не допускается передача сообщений ICMP об ошибках в результате приема следующих пакетов20:
♦ сообщение ICMP об ошибке
♦ дейтаграммы с групповым или широковещательным адресом IP
♦ дейтаграммы, переданные как широковещательные на канальном уровне
♦ фрагмент, не являющийся первым
♦ дейтаграммы, для которых адрес отправителя не определен как один хост (например, нулевой адрес, loopback-адрес, широковещательный или групповой адрес, адрес класса E).
Обсуждение:
Эти правила будут предотвращать возникновение “широковещательных штормов” (broadcast storms)
19 С момента разработки этого документа число типов ICMP было расширено (см. RFC). Прим. перев.
20 Приведенные здесь требования имеют превосходство над всеми остальными требованиями, указанными в этом документе для передачи сообщений ICMP.
Перевод на русский язык - Н. Малых 18 rfc.com.ru
|
||
|
|
||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
при получении хостом ICMP-сообщения об ошибке в ответ на широковещательную дейтаграмму. Например, широковещательный сегмент UDP, адресованный в несуществующий порт, может инициировать лавину дейтаграмм ICMP Destination Unreachable от всех машин, которые не обслуживают указанный в дейтаграмме порт.В большой сети Ethernet такая лавина может привезти к остановке сети на несколько секунд в результате возникновения коллизий.
Каждая дейтаграмма, передаваемая в широковещательном режиме в подключенную сеть, должна содержать корректный широковещательный адрес IP для своих получателей (см. параграф 3.3.6). Однако, некоторые хосты не соблюдают это правило, поэтому каждый хост должен проверять широковещательные адреса канального уровня и широковещательные адреса IP.
Реализация
Канальный уровень должен информировать уровень IP о получении широковещательных для канального уровня дейтаграмм (см. параграф 2.4).
3.2.2.1 Destination Unreachable: RFC-792
Для сообщений этого типа определены дополнительные коды:
6 - неизвестна сеть адресата
7 - неизвестен хост-адресат
8 - изолированный хост-отправитель
9 - связь с сетью адресата административно запрещена
10 - связь с хостом-адресатом административно запрещена
11 - сеть недоступна для заданного типа обслуживания
12 - хост недоступен заданного типа обслуживания Рекомендуется для хостов генерировать сообщения Destination Unreachable с кодами:
2 (Protocol Unreachable - протокол недоступен) - указанный транспортный протокол не поддерживается
3 (Port Unreachable - порт недоступен) - указанный транспортный протокол (например, UDP) не может демультиплексировать дейтаграмму и нет механизма передачи отправителю уведомления.
Принятые сообщения Destination Unreachable должны передаваться на транспортный уровень. Транспортный уровень должен использовать полученную информацию подобающим образом (см. примеры в параграфах 4.1.3.3, 4.2.3.9, 4.2.4). Транспортный протокол, обеспечивающий собственный механизм уведомления отправителя о недоступности портов (например, TCP при передаче сегментов RST), никогда не должен воспринимать сообщения ICMP Port Unreachable для решения этой задачи.
Сообщение Destination Unreachable, принятое с кодом 0 (Net - сеть), 1 (Host - хост) или 5 (Bad Source Route - некорректный маршрут от отправителя), может приходить от транзитного маршрутизатора и должно интерпретироваться как намек (не доказательство) на то, что адресат может быть недоступен [IP:11].В частности, такие сообщения не могут служить доказательством неработоспособности маршрутизатора (см. параграф 3.3.1).
3.2.2.2 Redirect: RFC-792
Хостам не рекомендуется передавать сообщений ICMP Redirect, поскольку эти сообщения являются прерогативой маршрутизаторов.Хост, получивший сообщение Redirect, должен соответственно скорректировать свою маршрутную информацию.Каждый хост должен быть готов к приему сообщений Host Redirect и Network Redirect для их обработки в соответствии с рекомендациями параграфа 3.3.1.2.
Сообщения Redirect рекомендуется отбрасывать без уведомления, если указанный в них новый шлюз не находится в той же (под)сети, через которую было доставлено сообщение Redirect [INTRO:2, Appendix A], или сообщения Redirect приходят от маршрутизатора, который не указан как first-hop (первый маршрутизатор) для данного получателя (см. параграф 3.3.1).
3.2.2.3 Source Quench: RFC-792
Хост может передавать сообщения Source Quench в тех случаях, когда он находится или приближается к состоянию необходимости отбрасывания входящих дейтаграмм в результате переполнения буферов сборки или нехватки других ресурсов.Более подробную информацию по этому вопросу вы сможете найти в параграфе 2.2.3 работы [INTRO:2].
При получении сообщения Source Quench уровень IP должен сообщить о нем транспортному уровню (или системе обработки сообщений ICMP).В общем случае транспортный или прикладной уровень должен обеспечивать механизм реакции на сообщения Source Quench для всех протоколов, которые могут передавать последовательность дейтаграмм одному адресату и способны поддерживать достаточно информации о состоянии, чтобы сделать возможной реакцию на такие сообщения.Обработка сообщений Source Quench протоколами TCP и UDP описана в главе 4.
Обсуждение:
Сообщения Source Quench могут генерироваться хостами-получателями или некоторыми шлюзами по пути передачи дейтаграмм.Хост, получивший сообщение Source Quench, должен снизить уровень трафика для данного получателя на некоторое время и потом постепенно восстанавливать его. Механизм реакции на сообщения Source Quench может быть реализован на транспортном (для
Перевод на русский язык - Н. Малых 19 rfc.com.ru
|
||
|
|
||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
протоколов на основе соединений типа TCP) или прикладном (для протоколов, работающих поверх UDP) уровне.В работе [IP:14] предложен механизм для уровня IP, позволяющий непосредственно реагировать на сообщения Source Quench за счет управления скоростью передачи дейтаграмм, однако это предложение пока является только экспериментальным и не может быть рекомендовано для использования.
3.2.2.4 Time Exceeded: RFC-792
Принимаемые сообщения Time Exceeded должны передаваться на транспортный уровень.
Обсуждение:
Маршрутизаторы передают сообщение Time Exceeded с кодом 0 (In Transit) при получении дейтаграмм с нулевым значением TTL (время жизни).Такая ситуация может говорить о наличии петель в маршрутизации или слишком малом значении TTL при генерации дейтаграммы.
Хост может получать сообщения Time Exceeded с кодом 1 (Reassembly Timeout - тайм-аут при сборке) от хоста-адресата, который не смог в заданное время получить все фрагменты и собрать дейтаграмму (такие дейтаграммы отбрасываются - см. параграф 3.3.2). В будущем такие сообщения могут стать частью некоторых процедур MTU discovery, используемых для определения максимального размера дейтаграмм, которые можно передать без фрагментации.
3.2.2.5 Parameter Problem: RFC-792
Для хостов рекомендуется генерировать сообщения Parameter Problem.Принимаемые сообщения Parameter Problem должны передаваться на транспортный уровень и, кроме того, информация о таких сообщениях может передаваться пользователю.
Обсуждение:
Сообщения ICMP Parameter Problem передаются хосту-отправителю при обнаружении любых проблем, для которых нет специализированных сообщений ICMP.Появление сообщений Parameter Problem обычно служит сигналом о наличии ошибок в работе протоколов на локальном или удаленном хосте.
Ниже определяется новое значение кода для сообщений Parameter Problem:
1 = отсутствует обязательный параметр.
Обсуждение:
Этот код уже используется в военных приложениях при отсутствии опций безопасности.
3.2.2.6 Echo Request/Reply: RFC-792
Каждый хост должен поддерживать функции сервера ICMP Echo, обеспечивающие прием запросов Echo Request и передачу в ответ на них сообщений Echo Reply. Рекомендуется также реализовать интерфейс прикладного уровня для передачи сообщений Echo Request и получения откликов Echo Reply с диагностическими целями.
Сообщения ICMP Echo Request, полученные с групповым или широковещательным адресом IP, можно отбрасывать без уведомления.
Обсуждение:
Здесь приводятся беспристрастные результаты дебатов между теми, кто считает, что отклики на широковещательные запросы ICMP Echo обеспечивают эффективные возможности для диагностики, и теми, кто утверждает, что с помощью таких откликов очень легко создать пакетные бури.
IP-адрес отправителя в откликах ICMP Echo Reply должен совпадать с указанным адресом получателя (см. определение в 3.2.1.3) из соответствующего сообщения ICMP Echo Request.
Данные, получаемые в запросе ICMP Echo Request, должны полностью включаться в результирующий отклик Echo Reply.Однако, если передача Echo Reply требует преднамеренной фрагментации, которая не реализована, дейтаграмма должна быть усечена (truncate) до размера MTU (см. параграф 3.3.3).
Сообщения Echo Reply должны передаваться на пользовательский интерфейс ICMP, если соответствующий запрос Echo Request не направлен на уровень IP.
Если в запросе ICMP Echo Request присутствует опция Record Route и/или TimeStamp, эта опция(и) должна быть обновлена с включением в маршрут текущего хоста и вставлена в заголовок IP отклика Echo Reply без “усекновения” (truncation).Таким образом, сохраняется записанный маршрут для замкнутого кольца.
Если в запросе ICMP Echo Request присутствует опция Source Route, маршрут возврата должен быть инвертирован и вставлен в поле Source Route сообщения Echo Reply.
3.2.2.7 Information Request/Reply: RFC-792
Для хостов рекомендуется не реализовать эти сообщения.
Обсуждение:
Пара сообщений Information Request/Reply была предназначена для поддержки самонастраиваемых систем типа бездисковых станций, чтобы позволить им получать IP-адреса в процессе загрузки.Однако протоколы RARP и BOOTP обеспечивают более эффективные механизмы получения хостами IP-адресов.
3.2.2.8 Timestamp/Timestamp Reply: RFC-792
Хост может поддерживать сообщения Timestamp и Timestamp Reply.Если такая поддержка реализована,
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
20
|
|||
|
|
||||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
должно выполняться следующее правило.
♦ Функция сервера ICMP Timestamp возвращает сообщение Timestamp Reply в ответ на каждое принятое сообщение Timestamp.Если эта функция реализована, она должна обеспечивать минимальные вариации задержки (т.е. функция должна быть включена в ядро, чтобы избежать вариаций задержки, связанных с пользовательскими процессами).
В перечисленных ниже случаях обработка Timestamp должна соответствовать правилам для ICMP Echo:
♦ Сообщения Timestamp Request с групповыми и широковещательными адресами IP можно отбрасывать без уведомления.
♦ IP-адрес отправителя в сообщении Timestamp Reply должен совпадать с адресом получателя, указанным в соответствующем запросе Timestamp.
♦ При получении опции Source-route в запросе Timestamp, путь возврата должен инвертироваться при создании опции Source Route для отклика Timestamp Reply.
♦ При наличии опции Record Route и/или Timestamp в запросе Timestamp Request, эти опции рекомендуется обновлять с включением текущего хоста и помещать обновленное значение в поле заголовка IP для сообщения Timestamp Reply.
♦ Входящие сообщения Timestamp Reply должны передаваться пользовательскому интерфейсу ICMP. Предпочтительной формой временных меток ("стандартное значение") является число миллисекунд с полуночи по Стандартному времени (Universal Time).Однако временные метки с таким разрешением могут быть слишком сложны в реализации.Например, во многих системах используются часы, синхронизируемые от электросети (50 или 60 Гц) - следовательно, такие системы не могут обеспечить требуемого разрешения. Поэтому допускается отклонение от стандартного значения:
(a) "Стандартное значение" должно обновляться не менее 15 раз в секунду (т.е.не менее 6 младших битов должны быть неопределенными).
(b) Точность "стандартного значения" должна приближаться к точности таймера CPU.
3.2.2.9 Address Mask Request /Reply: RFC-950
Хост должен поддерживать первый и может реализовать все три из перечисленных ниже методов определения адресных масок, соответствующих IP-адресам этого хоста:
(1) статические конфигурационные параметры;
(2) динамическое определение масок в процессе инициализации системы (см. [INTRO:1]);
(3) передача сообщений ICMP Address Mask Request и прием откликов ICMP Address Mask Reply. Для каждого хоста требуется обеспечить выбор используемого метода. При использовании метода (3) можно применять Address Mask и должны выполняться следующие условия:
(a) При инициализации хост должен передать с широковещательным адресом сообщение Address Mask Request в подключенную сеть.Если ответ Address Mask Reply не приходит незамедлительно, должно использоваться минимальное число повторов.
(b) До получения отклика Address Mask Reply хосту рекомендуется предполагать, что маска соответствует классу адреса данного хоста (т. е. подключенная сеть не поделена на подсети).
(c) Первое принятое сообщение Address Mask Reply должно использоваться для установки адресной маски, соответствующей частному локальному адресу IP.Это верно даже в тех случаях, когда первое сообщение Address Mask Reply не было запрошено (unsolicited) - в таких случаях оно будет широковещательным и может прийти после того, как хост перестал передавать повторные запросы Address Mask Request.После того, как маска была установлена с использованием Address Mask Reply, последующие сообщения Address Mask Reply должны игнорироваться.
Если сообщения Address Mask запрещены, запросы ICMP Address Mask Request не будут передаваться и все принятые отклики ICMP Address Mask Reply для локального IP-адреса должны игнорироваться.
Для хостов рекомендуется выполнять некоторые разумные проверки устанавливаемых адресных масок (см. “Реализация” ниже).
Система не должна передавать никаких откликов Address Mask Reply, если она не является уполномоченным агентом для адресных масок.Уполномоченный агент может быть хостом или шлюзом, но он должен быть явно настроен как агент для адресных масок.Получение адресных масок с помощью Address Mask Reply не дает получателю таких прав и не может использоваться как основание для передачи откликов Address Mask Reply.
При статически заданных адресных масках рекомендуется использовать дополнительный конфигурационный флаг, определяющий для хоста возможность выступать в качестве уполномоченного агента для масок (может ли этот хост отвечать на запросы Address Mask Request с использованием маски).
Настроенный как агент хост должен передать в широковещательном режиме сообщение Address Mask Reply для маски инициализируемого интерфеса.
Дополнительные сведения об использовании сообщений Address Mask Request/Reply приведены в параграфе System Initialization работы [INTRO:1].
Обсуждение
Хосты, передающие сообщения Address Mask Reply, часто могут порождать серьезные проблемы.Для предотвращения этого отклики Address Mask Reply должны передаваться только уполномоченными агентами, явно указанными администратором сети.
Когда уполномоченный агент получает сообщение Address Mask Request, он будет передавать отклик Address Mask Reply по IP-адресу отправителя запроса.Если сетевая часть этого адреса имеет нулевое
Перевод на русский язык - Н. Малых 21 rfc.com.ru
|
||
|
|
||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
значение (см. (a) и (b) в параграфе 3.2.1.3), отклик передается в широковещательном режиме.
Не получив отклика на сообщения Address Mask Request, хост будет предполагать отсутствие агентов или подсетей, но причиной отсутствия отклика может быть временная недоступность агента.Агент будет передавать в широковещательном режиме незапрашиваемые сообщения Address Mask Reply при своей инициализации для обновления масок на всех хостах, которые были инициализированы в период недоступности агента.
Реализация
Предлагается выполнять следующую проверку адресной маски - в маске не должны содержаться только 1 и старшие 8 битов должны быть установлены в 1 или вся маска должна быть нулевой.
3.2.3 Протокол IGMP (Internet Group Management Protocol)
Протокол IGMP [IP:4] используется хостами и маршрутизаторами одной сети для организации и поддержки членства хостов в multicast-группах.Шлюзы используют этот протокол вместе с протоколом групповой маршрутизации (multicast routing) для поддержки трафика IP multicast через Internet.
В настоящее время реализация IGMP является необязательной (см. параграф 3.3.7). Без использования IGMP хосты могут участвовать в multicast-группах подключенной сети.
3.3 Частные вопросы
3.3.1 Маршрутизация исходящих дейтаграмм
Уровень IP выбирает следующий маршрутизатор (next hop) для каждой передаваемой дейтаграммы.Если получатель находится в подключенной сети, дейтаграмма передается на этот хост напрямую; в остальных случаях дейтаграмма направляется маршрутизатору подключенной сети.
3.3.1.1 Выбор Local/Remote
Для определения принадлежности хоста к подключенной сети должен использоваться следующий алгоритм [см. IP:3]:
(a) Адресная маска (применительно к локальному IP-адресу для многодомного хоста) представляет собой 32-битовое значение, позволяющее выбрать поля номеров сети и подсети в адресах IP.
(b) Если биты IP-адреса получателя, извлеченные с помощью маски21, совпадают с битами IP-адреса отправителя, полученным с такой же маской, это говорит о принадлежности хоста к подключенной сети и дейтаграмма передается напрямую хосту-получателю.
(c) Если условие (b) не выполняется, для доставки дейтаграммы должен использоваться шлюз, определяемый в соответствии с требованиями параграфа 3.3.1.2.
Для некоторых специальных случаев используется иной алгоритм:
♦ для групповых и широковещательных адресов ограниченного действия дейтаграммы просто передаются на канальный уровень через соответствующий интерфейс.
♦ Для широковещательных дейтаграмм, адресованных всей сети или подсети, могут использоваться стандартные алгоритмы маршрутизации.
IP-уровень хоста должен корректно работать в минимальной сетевой среде (в частности, при отсутствии маршрутизаторов).Если IP-уровень хоста упорно ищет хотя бы один шлюз при инициализации, такой хост не сможет работать в изолированной сети.
3.3.1.2 Выбор шлюза
Для эффективной маршрутизации группы дейтаграмм одному получателю хост-отправитель должен сохранять “кэш маршрутов” (Route Cache).Хост использует описанный ниже алгоритм для маршрутизации дейтаграмм с использованием кэша (алгоритм предназначен прежде всего для переноса основного бремени маршрутизации на шлюзы) [IP: 11].
♦ Если кэш маршрутов не содержит информации для интересующего адреса, хост выбирает принятый по умолчанию шлюз и передает дейтаграмму этому маршрутизатору.Соответствующая запись вносится в кэш маршрутов.
♦ Если шлюз не является лучшим путем к адресату, он должен будет переслать детаграмму наиболее подходящему маршрутизатору и вернуть хосту-отправителю сообщение ICMP Redirect.
♦ Получив сообщение Redirect, хост обновляет шлюз в соответствующей записи кэша для того, чтобы последующие дейтаграммы доставлялись по более эффективному пути.
Поскольку маска сети для адреса получателя в общем случае неизвестна, сообщения Network Redirect должны трактоваться аналогично сообщениям Host Redirect, т.е. запись в кэше для хоста-получателя (и только для него) будет обновляться (или создаваться, если ранее ее не было) с учетом нового шлюза.
Обсуждение:
Эта рекомендация предназначена для защиты от шлюзов, передающих сообщения Network Redirect в сеть с подсетями, в нарушение требований к маршрутизаторам [INTRO:2].
При отсутствии в кэше записи для адреса получателя (если адресат не находится в подключенной сети) уровень IP должен выбрать маршрутизатор из своего списка принятых по умолчанию шлюзов (default gateway). Уровень IP должен поддерживать множество используемых по умолчанию шлюзов.
В качестве дополнительной возможности уровень IP хоста может реализовать таблицу статических
21 Операция AND. Прим. перев.
Перевод на русский язык - Н. Малых 22 rfc.com.ru
|
||
|
|
||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||||
|
|
||||
|
маршрутов (static route).Каждый статический маршрут может включать флаг, определяющий возможность переписывания этого маршрута с помощью ICMP Redirect.
Обсуждение:
Для начала работы хосту требуется знать по крайней мере один используемый по умолчанию шлюз.Эту информацию можно получить из конфигурационного файла или загрузочного сценария (например, BOOTP - [INTRO:1]).
Предполагается, что хост может расширять список используемых по умолчанию шлюзов, добавляя в него маршрутизаторы по мере их обнаружения.Например, хост может записывать каждый шлюз, на который пересылает пакеты.Такое решение может оказаться очень эффективным для некоторых случаев, но в иных ситуациях (не все маршрутизаторы одинаковы) оно может порождать проблемы и, поэтому, не рекомендуется.
Статический маршрут представляет собой отображение хоста или сети на тот или иной следующий маршрутизатор (next-hop gateway); маршрут может также зависеть от типа обслуживания (ToS), рассматриваемого в следующем параграфе.Статические маршруты устанавливаются администратором сети взамен нормальных механизмов автоматической маршрутизации и для обслуживания исключительных ситуаций.Однако, следует помнить, что статические маршруты являются потенциальным источником ошибок при изменении конфигурации или повреждениях оборудования.
3.3.1.3 Кэш маршрутов
Каждая запись в кэше маршрутов должна содержать следующие поля:
(1) локальный IP-адрес (для многодомных хостов)
(2) IP-адрес получателя
(3) тип(ы) обслуживания ToS
(4) IP-адрес следующего маршрутизатора
Поле (2) может содержать полный адрес получателя или только адрес сети, в которую тот входит.Поле TOS (3) должно присутствовать в записи.
Процедуры работы с кэшем маршрутов описаны в параграфе 3.3.4.2.
Обсуждение:
Включение поля Type-of-Service в кэш маршрутов и его рассмотрение в алгоритме маршрутизации будет обеспечивать механизм для применения в будущем маршрутизации по типу обслуживания в сети Internet (см. параграф 3.2.1.6).
Каждая запись в кэше определяет конечную точку пути через Internet.Хотя маршрут между двумя точками может динамически изменяться, характеристики пути передачи остаются почти неизменными в течение продолжительного времени для каждого транспортного соединения между парой хостов.
Следовательно, запись в кэше маршрутов является естественным местом для хранения информации о свойствах пути.Примером такого свойства может служить максимальный размер нефрагментируемой дейтаграммы (см. параграф 3.3.3) или средняя задержка на круговом пути, измеренная транспортным протоколом.
Эти данные в общем случае собираются и используются протоколами вышележащих уровней (например, TCP) или приложениями, использующими протокол UDP.В настоящее время ведутся эксперименты по кэшированию свойств путей описанным здесь способом.
Существуют разногласия по вопросу использования ключей для кэша - только адрес получателя или оба адреса (получателя и отправителя).Сторонники использования только адресов получателей приводят следующие агрументы:
(1) В соответствии с требованиями параграфа 3.3.1.2 сообщения Redirect будут порождать записи, ключами к которым являются адреса получателей; простейшая и наиболее общая схема всегда будет использовать адреса хостов.
(2) Уровень IP не всегда может знать адресную маску для сети получателя в сложной среде с подсетями.
(3) Использование только адресов хостов-получателей позволит применять полные 32-битовые адреса, обеспечивая восприимчивость к изменению архитектуры Internet.
Сторонники использования в качестве ключей адресов отправителей и получателей также приводят свои аргументы:
(1) экономия памяти.
(2) упрощение структуры данных, простота объединения с таблицами принятых по умолчанию и статических маршрутов (см. ниже).
(3) Обеспечивается больше полезного места для хранения информации о свойствах пути, как было упомянуто выше.
Реализация
Кэш должен быть достаточно велик и обеспечивать возможность включения записей для максимального числа хостов-получателей, которое может использоваться в каждый момент времени.
Маршрутная запись в кэше может также включать управляющую информацию, используемую для выбора заменяемой записи.Это может быть реализовано, например, в форме бита recently used (недавно использована) или временной метки для последнего обращения.В целях диагностики
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
23
|
|||
|
|
||||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
рекомендуется сохранять время последнего изменения записи.
При реализации может возникнуть желание снизить издержки на сканирование кэша маршрутов для каждой передаваемой дейтаграммы.Это можно реализовать с помощью хэш-таблицы для ускорения просмотра или путем предоставления оринетрированными на соединения протоколами транспортного уровня “советов” или временных указателей на подходящую запись в кэше уровню IP с каждой последовательной дейтаграммой.
Хотя мы рассматривали здесь кэш маршрутов и список используемых по умолчанию шлюзов по-отдельности один от другого, на практике их часто объединяют в одну структуру данных - routing table (таблица маршрутизации).
3.3.1.4 Обнаружение “мертвых” шлюзов
Уровень IP должен обеспечивать возможность обнаружения неработающих маршрутизаторов на следующем интервале (next-hop gateway), включенных в кэш маршрутов, и выбора других маршрутов взамен поврежденных (см. параграф 3.3.1.5).
Процесс обнаружения сбойных маршрутизаторов детально рассмотрен в RFC-816 [IP:11]. До сегодняшнего дня не разработано полного алгоритма, обеспечивающего эффективное обнаружение сбойных маршрутов, хотя предложен целый ряд методик.
♦ Не рекомендуется использовать конкретный маршрутизатор при отсутствии признаков его работоспособности.
♦ Активные средства проверки типа ping (т.е., использование сообщений ICMP Echo Request/Reply) слишком накладны и не обеспечивают требуемого масштабирования.В частности, следует отметить, что недопустимо проверять состояние первого маршрутизатора путем непрерывной передачи по его адресу запросов ICMP.
♦ Даже при отсутствии других способов проверки состояния маршрутизатора ping следует использовать только в случаях отсутствия подтверждений работы маршрутизатора при передаче ему реального трафика, что позволяет усомниться в работоспособности маршрутизатора.
♦ Чтобы избежать использования ping уровни выше и ниже IP должны обеспечивать возможность получения сведений о состоянии пути в кэше маршрутов за счет использования позитивной (маршрутизатор работает) или негативной информации о состоянии шлюза.
Обсуждение:
Если реализация не включает адекватного механизма обнаружения неработающих маршрутизаторов, сбой в маршрутизаторе будет приводить к пропаданию пакетов в “черной дыре”. Такие ситуации вызывают массу нареканий со стороны пользователей и весьма сложны для обнаружения.
Механизм обнаружения “мертвых” маршрутизаторов не должен создавать неприемленмой нагрузки на хост, подключенную сеть или соседние маршрутизаторы.Продожительность детектирования и приемлемый уровень нагрузки в некоторой степени зависят от характера использования хоста, но в общем случае требуется достаточно быстро находить повреждение в ближайшем маршрутизаторе (first-hop gateway), чтобы не нарушалась работа приложений транспортного уровня, не использующих прямых соединений (connections) за время детектирования сбоя и поиска альтернативного пути.
Передача информации от соседних уровней стека протоколов усложняет интерфейс между уровнями, но может существенно упростить обнаружение сбойных маршрутизаторов.Информация может приходить почти от всех элементов архитектуры IP/TCP, но наиболее важны сведения от транспортного и канального уровней. Ниже приведены примеры такой информации:
♦ TCP или другой протокол на основе соединений должен обеспечивать возможность получения негативной информации (например, слишком большо число повторных передач).
♦ TCP может давать позитивную информацию после получения (нового) подтверждения о доставке данных.Даже при асимметричном маршруте такое подтверждение свидетельствует об успешной передаче.
♦ Сообщения ICMP Redirect от конкретных маршрутизаторов должны использоваться как позитивные сведения о работе шлюза.
♦ Информация канального уровня, который способен эффективно детектировать сбои и сообщать о них (например, с помощью сообщений ARPANET Destination Dead), должна использоваться как негативные сведения.
♦ Сбои в работе ARP или при проверке отображений (преобразований) ARP могут использоваться как негативная информация для соответствующих адресов IP.
♦ Поступление пакетов от конкретного адреса канального уровня является подтверждением работы соответствующего устройства.Однако включение таких данных в сведения о работоспособности шлюзов требует отображения адресов канального уровня в адреса IP и последующей проверки принадлежности этих адресов указанным в кэше маршрутов шлюзам.Такое решение может оказаться недостаточно эффективным.
Отметим, что использование позитивных сведений от каждой полученной дейтаграммы может привести к чрезмерной загрузке системы.
Сведения могут передаваться с использованием требуемых аргументов во все интерфейсы с IP-уровнем, однако некоторые транспортные и прикладные протоколы не способны генерировать
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
24
|
|||
|
|
||||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||||
|
|
||||
|
корректные анонсы.Такие интерфейсы, следовательно, должны поддерживать нейтральные сведения, поскольку передача анаонса с неверным знаком (позитив - негатив) может привести к некорреткной работе системы.
Существуют (и широко распространен) иной метод определения “мертвых” маршрутизаторов, но его использование не рекомендуется.Этот метод основан на получении хостом (в пассивном режиме) (wiretapping) дейтаграмм протокола IGP (Interior Gateway Protocol), которыми маршрутизаторы обмениваются между собой.Такое решение имеет существенный недостаток - хосты должны распознавать все протоколы внутренних шлюзов, которые маршрутизатор может использовать (см. [INTRO:2]). Кроме того, такой вариант будет работать только в широковещательной сети.
В настоящее время ping (т.е.использование сообщений ICMP Echo) используется как механизм для проверки работоспособности маршрутизаторов только при возникновении абсолютной необходимости.Отклики на ping гарантируют работоспособность проверяемого интерфейса и связанной с ним машины, но они не гарантируют возможности передачи дейтаграмм в другие интерфейсы маршрутизатора.При наличии сообщений Redirect или иных явных признаков того, что машина является шлюзом, отклики на ping будут говорить о том что маршрутизатор успешно выполняет свои функции.Однако отбрасывание хостом без уведомления пакетов, которые маршрутизатор должен пересылать или перенаправлять, может приводить к тому, что такое предположение перестанет быть верным.Чтобы избежать подобных проблем, разрабатывается новый тип сообщений "are you a gateway?" (это маршрутизатор?).
Реализация
Для обнаружения “мертвых” маршрутизаторов предлагается следующий алгоритм:
♦ Связать таймер “повторной маршрутизации” (reroute timer) с каждым шлюзом, на который указывает запись в кэше маршрутов.При инициализации таймера устанавливается значение Tr, которое должно быть достаточно мало, чтобы можно было обнаружить неработающий маршрутизатор до того, как транспортное соединение будет разорвано по тайм-ауту.
♦ Позитивные сведения будут сбрасывать таймер в Tr, а негативные - обнулять таймер.
♦ Всякий раз, когда уровень IP используется для маршрутизации дейтаграммы, должно проверяться состояние таймера.Если таймер содержит нулевое значение, уровень IP будет использовать ping для данного шлюза.
♦ Пакеты ping (ICMP Echo) можно при необходимости повторять до N раз.Если за N попыток не было получено ни одного отклика, делается вывод о неработоспособности маршрутизатора и в кэше должен указываться новый шлюз для всех записей, указывающих на сбойный маршрутизатор.
Отметим, что значение Tr обратнопропорционально числу возможных анонсов.Значение Tr должно быть достаточно мало, чтобы обеспечить следующие условия:
♦ Пакеты ping должны составлять достаточно малую часть (например, <10%) от всех пакетов, передаваемых маршрутизатору с данного хоста.
♦ Пакеты ping должны передаваться достаточно редко (например, каждые 3 минуты).
Поскольку описанный алгоритм имеет дело с маршрутизаторами, на которые указывают записи в кэше маршрутов, а не с самими записями, для реализации этого алгоритма желательно использовать двухуровневую структуру кэша (например, по типу кэша ARP).
3.3.1.5 Выбор нового шлюза
Если прекративший работать шлюз не является в настоящий момент используемым по умолчанию, уровень IP может незамедлительно переключиться на работу с принятым по умолчанию маршрутизатором.При сбое в работе установленного по умолчанию шлюза уровень IP должен выбрать другой маршрутизатор для использования по умолчанию (предполагается, что может существовать несколько таких шлюзов) на прекратившем работу пути и организовать новые маршруты.
Обсуждение:
В случае прекращения работы маршрутизатора другие шлюзы подключенной сети узнают об этом с помощью некоторых протоколов обмена информацией между маршрутизаторами.Однако, это не происходит моментально, поскольку протоколы маршрутизации имеют время обмена порядка 30-60 секунд.Если хост переключится на другой маршрут до того, как выбранный маршрутизатор узнает о сбое, этот маршрутизатор может попытаться переслать дейтаграмму вышедшему из строя шлюзу и послать отправителю дейтаграммы сообщение Redirect, указывающее на “мертвый” маршрутизатор (!). В результате этого может начаться процесс автогенерации обновлений кэша маршрутов до того, как маршрутизатор узнает о прекращении работы другого шлюза.Для предотвращения таких ситуаций логика обнаружения “мертвых” маршрутизаторов должна обеспечивать некоторый гистерезис (запаздывание).Однако, на практике упомянутые случаи автогенерации обновлений случаются редко, поскольку обслуживание хоста не может быть восстановлено до тех пор, пока шлюз не организует маршрутную информацию.
Реализация
Одним из вариантов реализации выбора нового маршрута по умолчанию является просто циклический перебор хостом своего списка используемых по умолчанию шлюзов.Другим вариантом является ранжирование маршрутизаторов по уровню приоритета и использование по умолчанию шлюза с максимальным приоритетом.Если в данный момент текущим является маршрутизатор не с высшим приоритетом, хост использует ping (достаточно редкие запросы), чтобы обнаружить восстановление
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
25
|
|||
|
|
||||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
работы маршрутизатора с высшим приоритетом.Частота запросов может быть очень низкой, порядка одного запроса в 3 минуты.
3.3.1.6 Инициализация
Должна обеспечиваться возможность настройки следующих параметров:
(1) IP-адреса.
(2) Маски адресов.
(3) Список используемых по умолчанию шлюзов с уровнем приоритета для каждого.
Должна обеспечиваться возможность ручной настройки перечисленных параметров и, кроме того, могут использоваться различные методы динамического определения параметров (см.параграф "Инициализация хоста" в [INTRO:1]).
Обсуждение:
Некоторые реализации хостов прослушивают (wiretapping) протоколы маршрутизации в широковещательной сети для обнаружения шлюзов.Стандартный метод определения используемых по умолчанию шлюзов находится в стадии разработки22.
3.3.2 Сборка (Reassembly)
Уровень IP должен обеспечивать сборку из фрагментов (reassembly) дейтаграмм IP.
Будем обозначать максимальный размер дейтаграммы, которая может быть собрана, как EMTU_R (Effective MTU to receive - эффективное значение MTU для приема); иногда используется термин “размер буфера сборки” (reassembly buffer size).Значение EMTU_R должно быть не менее 576 (байтов) и рекомендуется обеспечивать возможность настройки этого значения или использования неограниченного буфера сборки. Кроме того, это значение рекомендуется делать не меньше, чем значение MTU для подключенных сетей.
Обсуждение:
Фиксированное значение предела EMTU_R не должно встраиваться в программный код, поскольку некоторые протоколы прикладного уровня требуют использования EMTU_R > 576.
Реализация
При реализации можно использовать непрерывный буфер сборки для каждой дейтаграммы или применять более сложные структуры данных, позволяющие собирать дейтаграммы неопределенно большого размера; в последнем случае говорят о неограниченном (indefinite) EMTU_R.
Логически сборка представляет собой просто копирование каждого фрагмента в буфер с использованием указанного смещения.Отметим, что фрагменты дейтаграмм могут перекрываться в результате повторной передачи после нового фрагментирования с сохранением идентификатора.
Некоторую хитрость при сборке представляет учет (bookkeeping) для определения момента, когда собраны все фрагменты дейтаграммы.Мы рекомендуем алгоритм Кларка (Clark) [IP:10], не требующий дополнительного пространства памяти для учета.Однако, следует отметить, что в отличие от сказанного в [IP:10], заголовок первого фрагмента должен быть сохранен для включения в возможное сообщение ICMP Time Exceeded (Reassembly Timeout - тайм-аут при сборке).
Должен обеспечиваться механизм, посредством которого транспортный уровень будет определять значение MMS_R - маскимальный размер сообщения, которое может быть принято и собрано в дейтаграмму IP (см.функцию GET_MAXSIZES в параграфе 3.4).Если используется неограниченное значение EMTU_R, величина MMS_R определяется как MMS_R = EMTU_R - 20 (минимальный размер заголовка IP).
Для сборки должно задаваться максимальное время (тайм-аут).Значение тайм-аута рекомендуется делать фиксированным, а не привязывать его к оставшемуся времени жизни (TTL).Рекомендуется устанавливать тайм-аут в диапазоне 60 - 120 секунд.По истечении заданного времни частично собранные дейтаграммы должны отбрасываться с передачей сообщений ICMP Time Exceeded хосту-отправителю (если получен начальный фрагмент).
Обсуждение:
Спецификация IP говорит, что тайм-аут для сборки должен быть равен оставшемуся времени жизни дейтаграммы (TTL) из заголовка IP, но такое решение не работает должным образом, поскольку маршрутизаторы в общем случае трактуют TTL просто как счетчик интервалов, а не время доставки. Если тайм-аут для сборки слишком мал, дейтаграммы будут отбрасываться без нужды, что приведет к излишней загрузке коммуникационных каналов.Значение тайм-аута должно быть не меньше среднего времени доставки пакетов через Internet.Реальная оценка минимального значения тайм-аута составляет 60 секунд.
Предлагается сохранять в кэше значения времени на передачу дейтаграмм туда и обратно, измеряемые протоколами транспортного уровня и использовать эти значения для определения величины тайм-аута при сборке.Однако для использования таких методов требуются дополнительные исследования.
При установке слишком большого значения тайм-аута на принимающем хосте может не хватить выделенного для буферов пространства и время жизни сегмента MSL (Maximum Segment Lifetime) [TCP:1] станет слишком велико.Значение MSL управляет максимальной скоростью, с которой могут передаваться фрагменты дейтаграмм при использовании различных значений 16-битового поля идентификации (увеличение MSL снижает максимальную скорость).Спецификация TCP [TCP:1] предполагает для MSL значение 2 минуты.Эта величина устанавливает верхний предел для тайм-аута
|
||
|
|
||
|
22 См. RFC-1256 ICMP Router Discovery messages. Прим. перев.
Перевод на русский язык - Н. Малых 26 rfc.com.ru
|
||
|
|
||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
при сборке.
3.3.3 Фрагментация
Уровень IP может реализовать механизм преднамеренной фрагментации дейтаграмм.
Будем обозначать максимальный размер передаваемой дейтаграммы IP для конкретной комбинации отправитель - получатель (и возможно TOS), как EMTU_S (Effective MTU for sending - эффективное значение MTU для передачи).
Хост должен реализовать механизм, позволяющий транспортному уровню выяснять значение MMS_S (максимальный размер сообщения транспортного уровня, которое может быть передано) для данной комбинации {отправитель, получатель, TOS} (см.функцию GET_MAXSIZES в параграфе 3.4).Если локальной фрагментации не производится, должно выполняться условие:
MMS_S = EMTU_S - <размер заголовка IP>
и значение EMTU_S не должно быть больше MTU для сетевого интерфейса, соответствующего адресу отправителя дейтаграммы.Отметим, что значение <размер заголовка IP> в этом выражении будет равно 20, если IP не резервирует пространство для вставки опций IP в дополнение к опциям, устанавливаемым на транспортном уровне.
Хост, не реализующий локальную фрагментацию, должен обеспечивать получение транспортным (для TCP) или прикладным (для UDP) уровнем значения MMS_S от уровня IP и передачу дейтаграмм, размер которых не превышает MMS_S.
В общем случае желательно избегать локальной фрагментации и выбирать значение EMTU_S достаточно небольшим для того, чтобы избежать фрагментации на любом из шлюзов по пути доставки.При отсутствии актуальной информации о минимальном значении MTU для пути уровень IP должен использовать значение EMTU_S <= 576, если получатель не находится в подключенной сети (для этого случая используется принятое в сети значение MTU).
Значение MTU для каждого физического интерфейса должно быть настраиваемым.
Реализация уровня IP может использовать флаг конфигурации All-Subnets-MTU (MTU для всех подсетей), показывающий, что значение MTU в подключенной сети будет использоваться и для других подсетей этой сети (но не для других сетей).Таким образом, этот флаг заставляет использовать маску сети взамен маски подсети для выбора значения EMTU_S.Для многодомных хостов флаг All-Subnets-MTU требуется для каждого сетевого интерфейса.
Обсуждение:
Выбор корректного размера дейтаграмм для передачи данных является сложной задачей [IP:9].
(a) В общем случае от хоста не требуется прием дейтаграмм IP размером более 576 байтов (включая заголовок) и хост не должен передавать дейтаграмм большего размера без предварительного явного согласования с хостом-получателем.Таким образом, MMS_S задает только верхнюю границу размера дейтаграмм, которые может передавать транспортный уровень.Даже при MMS_S > 556 транспортный уровень должен ограничивать свои сообщения размером 556 байтов при отсутствии информации от хоста-получателя о возможности принимать более крупные сообщения.
(b) Некоторые транспортные протоколы (например, TCP) обеспечивают возможность явного уведомления отправителя о максимальном размере дейтаграмм, которые другая сторона может принимать и собирать [IP:7]. На уровне IP подобного механизма не существует.
Транспортный протокол, предполагающий EMTU_R > 576 (см. параграф 3.3.2), может передавать дейтаграммы большого размера другим хостам, поддерживающим такой же протокол.
(c) В идеальном случае хост должен ограничивать свое значение EMTU_S для данного получателя до минимального значения MTU во всех сетях на пути к получателю во избежание фрагментации. Фрагментация IP, будучи формально корректной, может существенно снижать производительность протокола транспортного уровня, поскольку потеря одного фрагмента будет требовать повторной передачи всех фрагментов сообщения [IP:9].
Поскольку практически все сети в среде Internet поддерживают MTU=>576, настоятельно рекомендуется использовать значение 576 для дейтаграмм, передаваемых за пределы локальной сети.
Для определения MTU на данном пути предлагается передавать фрагмент дейтаграммы с нулевым смещением и ожидать отклика ICMP Time Exceeded в результате тайм-аута при сборке (остальные фрагменты не передаются).Такое сообщение будет содержать заголовок самого большого из оставшихся фрагментов в своем теле.Ведутся эксперименты и с более прямыми механизмами, но они еще не адаптированы (см. например RFC-1063).
3.3.4 Локальные многодомные хосты
3.3.4.1 Введение
Многодомный хост имеет множество адресов IP, которые можно рассматривать как “логические интерфейсы".Эти интерфейсы могут быть связаны с одним или различными физическими интерфейсами, а последние могут быть соединены с одной или разными сетями.
Различается несколько вариантов многодомных хостов:
(a) Множество логических сетей
Создатели архитектуры Internet предполагали, что каждая физическая сеть будет иметь уникальный номер IP-сети (или подсети).Однако администраторы локальных сетей иногда считают полезным отказ от такого допущения и организуют в одной физической ЛВС множество логических сетей.
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
27
|
|||
|
|
||||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
Если хост, подключенный к такой физической сети, настроен на обслуживание трафика каждой из N различных логических сетей, этот хост будет иметь N логических интерфейсов.Эти интерфейсы могут использовать один или множество физических интерфейсов для подключения к одной физической сети.
(b) Множество логических хостов Когда хост имеет множество адресов IP с одинаковой сетевой частью (или одинаковым номером подсети), используется понятие логического хоста.Логические интерфейсы хоста могут использовать один или множество физических интерфейсов.
(c) Простой вариант В этом случае каждый логический интерфейс отображается на отдельный физический интерфейс, подключенный к своей физической сети.Термин “многодомный” изначально относился только к таким хостам, но сейчас толкование термина существенно расширилось.
Хост со встроенными функциями маршрутизации обычно представляет собой простой вариант многодомного хоста.Отметим, однако, что многодомный хост не обязан поддерживать встроенных функций маршрутизации (т.е.он может не реализовать пересылку пакетов из одной подключенной сети в другую).
Простой многодомный хост представляет наиболее серьезную проблему маршрутизации.Выбор интерфейса (т.е., сети first-hop) может существенно влиять на производительность и даже на доступность удаленных частей Internet.
В заключение отметим также обратный случай (это не многодомный хост), когда один логический интерфейс объединяет несколько физических интерфейсов (например, в целях повышения надежности или пропускной способности за счет организации параллельных каналов передачи данных между двумя точками сети).Например, две системы могут быть соединены множеством каналов “точка-точка”.Такой вариант мы будем называть мультиплексированием на канальном уровне (link-layer multiplexing).При таком мультиплексировании протоколы, расположенные выше канального уровня просто не знают о наличии множества физических интерфейсов - драйвер устройства на канальном уровне отвечает за мультиплексирование и маршрутизацию пакетов через разные физические интерфейсы.
В архитектуре протоколов Internet элемент протокола транспортного уровня не имеет собственного адреса, используя взамен один адрес IP.Это задача уровня IP - обеспечивать интерфейс для транспортного и прикладного уровней.В частности, прикладная программа может знать о множестве адресов IP многодомного хоста и выбирать один из них для своего использования.
3.3.4.2 Требования для многодомных хостов
Приведенные здесь правила применяются при выборе IP-адреса отправителя для передачи дейтаграмм многодомными хостами.
(1) Если дейтаграмма передается в ответ на принятую дейтаграмму, адрес отправителя должен совпадать с адресом получателя в принятой дейтаграмме.Более подробное описание требования для вышележащих уровней приведено в параграфах 4.1.3.5 и 4.2.3.7, а также в параграфе “Общие вопросы” работы [INTRO:1].
В остальных случаях адрес отправителя можно выбирать.
(2) Приложение должно быть способно явно указывать адрес отправителя при организации соединения или запросе.
(3) При отсутствии такой спецификации сетевые программы должны выбирать адрес отправителя в соответствии с приведенными ниже правилами.
С многодомными хостами связаны два ключевых вопроса:
A) Хост может отбрасывать без уведомления входящие дейтаграммы, в которых адрес получателя не соответствует физическому интерфейсу, принявшему дейтаграмму.
B) Хост может ограничить себя передачей дейтаграмм IP (не source-route) только через физический интерфейс, соответствующий IP-адресу отправителя в дейтаграмме.
Обсуждение:
Разработчики программ для хостов Internet используют две различных по концепции модели многодомных хостов, кратко рассмотренные ниже.В этом документе не отдается преимущества какой-либо модели - обе имеют свои плюсы и минусы.Различия между этими моделями, рассмотренные в (A) и (B), являются опциональными.
♦ Модель Strong ES
Модель Strong ES (End System - конечная система, т.е., хост) придает важное значение различиям
между хостами и маршрутизаторами (ES/IS) и применительно к ней следует изменить может на
должен в пунктах (A) и (B), рассмотренных выше.В этой модели многодомный хост представляется
как множество логических хостов в одном физическом компьютере.
Применительно к (A) сторонники модели Strong ES отмечают, что механизм автоматической
маршрутизации Internet не обеспечивает маршрутизации дейтаграмм в физические интерфейсы,
которые не соответствуют адресу получателя.
В модели Strong ES расчет маршрута для исходящих дейтаграмм представляет собой отображение:
маршрут(1Р-адрес отправителя, IP-адрес получателя, TOS) -> шлюз
Адрес отправителя включен как параметр для того, чтобы выбрать шлюз, напрямую доступный через соответствующий физический интерфейс.Отметим, что эта модель логически требует по крайней мере одного принятого по умолчанию шлюза и предпочитает иметь множество таких шлюзов для каждого IP-адреса отправителя.
Перевод на русский язык - Н. Малых 28 rfc.com.ru
|
||
|
|
||
|
|
||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||||
|
|
||||
|
♦ Модель Weak ES
В этой модели различия между хостами и маршрутизаторами не считаются существенными и следует использовать недопустимо вместо может для приведенных выше пунктов (A) и (B).Эта модель может быть более естественной для хостов, прослушивающих протоколы маршрутизации, и просто необходима для хостов с поддержкой встроенной маршрутизации.
Модель Weak ES может приводить к сбоям в работе механизма Redirect.Если дейтаграмма передана физическому интерфейсу, который не соответствует адресу получателя, первый (first-hop) маршрутизатор не сможет понять, когда ему нужно отправить сообщение Redirect.С другой стороны, хост поддерживающий функции маршрутизации, может получать маршрутную информацию без использования сообщений Redirect.
В модели Weak ES расчет маршрута для исходящих дейтаграмм представляет собой отображение:
маршрут(1Р-адрес получателя, TOS) -> шлюз, интерфейс
3.3.4.3 Выбор адреса отправителя
Обсуждение:
При передаче начального запроса соединения (например, сегмент TCP SYN) или дейтаграммы запроса обслуживания (например, UDP-запрос) транспортный уровень многодомного хоста должен знать, какой адрес отправителя нужно использовать.Если приложение не задало этот адрес, транспортный уровень должен запросить у IP-уровня концептуальное отображение:
CET_SRCADDR(yflafleHHbiii IP-адрес, TOS) -> локальный IP-адрес
Значение TOS задает тип обслуживания (см. 3.2.1.6) и результатом является нужный адрес отправителя. Для реализации такого отображения предлагаются следующие правила:
(a) Если удаленный адрес Internet относится к одной из (под)сетей, с которыми хост непосредственно соединен, может быть выбран соответствующий адрес отправителя, если нужный интерфейс находится в рабочем состоянии.
(b) Можно просмотреть кэш маршрутов для поиска активного маршрута в интересующую сеть через любой сетевой интерфейс.Если такой маршрут найден, можно выбрать локальный адрес IP, соответствующий интерфейсу.
(c) Аналогичным образом можно использовать и таблицу статических маршрутов (см. 3.3.1.2).
(d) Можно просмотреть список используемых по умолчанию шлюзов.Если такой шлюз связан с другими интерфейсами, можно выбрать шлюз с максимальным приоритетом.
В будущем может быть определен для многодомных хостов способ передачи маршрутизаторам всех подключенных сетей запросов для определения сети, наиболее подходящей для данного получателя.
Реализация
Отметим, что описанный процесс по сути совпадает с маршрутизацией дейтаграмм (см. 3.3.1) и, следовательно, хост может объединять реализацию этих функций.
3.3.5 Пересылка Source Route
С учетом приведенных ниже ограничений хост может выступать в качестве промежуточного интервала (intermediate hop) в маршруте source route, пересылая маршрутизируемые отправителем дейтаграммы на следующий указанный хост.
Однако, при выполнении таких функций квазимаршрутизации хост должен соответствовать всем требованиям, предъявляемым к шлюзам при пересылке дейтаграмм source route [INTRO:2].Эти требования имеют более высокий приоритет, нежели рассмотренные выше требования к хостам.
A) TTL (см. параграф 3.2.1.7)
Значение поля TTL должно декрементироваться и дейтаграмма может быть отброшена в соответствии с требованиями к шлюзам [INTRO:2].
B) ICMP Destination Unreachable (см. параграф 3.2.2.1)
Хост должен быть способен генерировать сообщения Destination Unreachable со следующими кодами:
4 (Fragmentation Required but DF Set), если дейтаграмма source route не может быть фрагментирована в соответствии с требованиями сети получателя;
5 (Source Route Failed), если дейтаграмму source route невозможно переслать (например, из-за проблем с маршрутизацией или в связи с тем, что следующий интервал при строгом задании маршрута (strict source route) не находится в подключенной сети.
C) IP-адрес отправителя (см. параграф 3.2.1.3)
Маршрутизируемые отправителем дейтаграммы при их пересылке могут иметь (в нормальных условиях имеют) адрес отправителя, который не является одним из IP-адресов пересылающего хоста.
D) Опция Record Route (см. параграф 3.2.1.8d)
Хост, пересылающий дейтаграммы source route, которые содержат опцию Record Route, должен обновлять значение этого поля, вписываю туда информацию о себе.
E) Опция Timestamp (см. параграф 3.2.1.8e)
Хост, пересылающий дейтаграммы source route, которые содержат опцию Timestamp, должен
|
||||
|
|
||||
|
Перевод на русский язык - Н. Малых
|
29
|
|||
|
|
||||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
добавлять в нее текущую временную метку в соответствии с правилами для этой опции.
Для определения правил, регулирующих работу хостов при пересылке дейтаграмм source route, мы будем использовать термин “локальная обработка” (local source-routing), если следующий шлюз доступен через тот же физический интерфейс, который принял дейтаграмму; в остальных случаях будет использоваться термин “нелокальная обработка” (non-local ource-routing).
♦ Хост может выполнять локальную обработку без каких-либо ограничений.
♦ Хост, поддерживающий нелокальную обработку, должен иметь конфигурационную опцию, позволяющую запретить перысылку и по умолчанию пересылка должна быть отключена.
♦ Хост должен соответствовать всем требованиям к шлюзам в части настройки политики фильтрации ([INTRO:2]), ограничивающей нелокальную обработку.
Если хост получает дейтаграмму с незавершенным маршрутом source route, но по тем или иным причинам не пересылает ее, он должен послать сообщение ICMP Destination Unreachable (код 5, Source Route Failed) отправителю дейтаграммы, если сама дейтаграмма не является сообщением ICMP об ошибке.
3.3.6 Широковещание
В параграфе 3.2.1.3 определены 4 стандартных формы широковещательных адресов IP: Limited Broadcast - ограниченная область: {-1, -1}
Directed Broadcast - широковещание для сети: {<Номер сети>,-1}
Subnet Directed Broadcast - широковещание для подсети: {<Номер сети>,<Номер подсети>,-1}
All-Subnets Directed Broadcast - широковещание для всех подсетей: {<Номер сети>,-1,-1}
Хост должен распознавать все эти форматы в поле получателя принимаемых дейтаграмм.
Существует класс хостов23, использующих нестандартный формат широковещательных адресов (0 взамен -1).Для всех хостов рекомендуется распознавать и принимать такие нестандартные форматы в полях адреса получателя для входящих дейтаграмм.Хост может использовать конфигурационную опцию для выбора формата (0 или -1) на каждом физическм интерфейсе, но по умолчанию должна применяться стандартная форма (-1).
Когда хост отправляет дейтаграмму по широковещательному адресу канального уровня, IP-адрес получателя должен быть корректным широковещательным или групповым адресом IP.
Для хостов рекомендуется отбрасывать без уведомления дейтаграммы, полученные в широковещательных кадрах канального уровня (см.2.4), если в них не указан широковещательный или групповой IP-адрес получателя.
Для рассылки широковещательных сообщений в подключенные сети рекомендуется использовать адреса формата Limited Broadcast.
Обсуждение:
Использование формата Limited Broadcast взамен Directed Broadcast может повысить устойчивость системы.Проблемы часто бывают вызваны машинами, которые не понимают до конца природы широковещательных адресов (см. 3.2.1.3) или используют собственные идеи о применении таких адресов.Типичным примером из прошлого являются машины, которые не понимают выделение подсетей, но подключены к сети, содержащей последние.Передача сообщений с адресом Subnet Broadcast для подключенной сети будет приводить к тому, что такие машины воспримут эти сообщения как адресованные другому хосту (не им).
Существует также вопрос о возможности передачи дейтаграмм с адресом формата Limited Broadcast через все интерфейсы многодомного хоста, однако этот вопрос выходит за пределы документа.
3.3.7 IP Multicasting
Хост должен поддерживать локальное использование групповой адресации (local IP multicasting) для всех подключенных сетей, на которых возможно отображение IP-адресов класса D на адреса канального уровня (см.ниже). Локальная поддержка групповой адресации включает передачу multicast-дейтаграмм, присоединение к multicast-группам, прием multicast-дейтаграмм и выход из multicast-групп.Сюда включается поддержка всех расширений [IP:4], за исключением протокола IGMP, поддержка которого не является обязательной.
Обсуждение:
Протокол IGMP обеспечивает шлюзы, поддерживающие маршрутизацию групповых адресов, информацией, требуемой для поддержки групповой адресации IP через множество сетей.В настоящее время multicast-маршрутизация находится в стадии экспериментов и доступна не везде.Для хостов, не подключенных к сетям с multicast-шлюзами, или в тех случаях, когда не нужно принимать multicast-дейтаграммы из других сетей, протокол IGMP не используется, поэтому его реализация не является обязательной.Однако, другие расширения [IP:4] в настоящее время рекомендованы в целях обеспечения доступа на уровне IP с локальной групповой адресацией как альтернатива локальной широковещательной адресации.Предполагается, что реализация IGMP тоже станет обязательной в будущем, когда multicast-маршрутизация получит более широкое распространение.
Если поддержка IGMP не реализована, для хостов рекомендуется сохранять принадлежность к группе all-hosts (все хосты) с адресом 224.0.0.1 при инициализации уровня IP и сохранять принадлежность к этой группе в течение всего периода активности уровня IP.
|
||
|
|
||
|
23 4.2BSD Unix и производные, но не 4.3BSD.
Перевод на русский язык - Н. Малых 30 rfc.com.ru
|
||
|
|
||
|
|
||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||
|
|
||
|
Обсуждение:
Включение в группу all-hosts будет обеспечивать локальную поддержку групповой адресации (например, протокол обнаружения шлюзов) даже без поддержки IGMP.
Отображение IP-адресов класса D на локальные адреса в настоящее время стандартизовано для следующих типов сетей:
♦ Ethernet/IEEE 802.3 в соответствии с [IP:4].
♦ Всех сетей, поддерживающих широковещательную, но не групповую адресацию (IP-адреса класса D отображаются на локальный широковещательный адрес).
♦ Всех типов каналов “точка-точка” (например, SLIP или HDLC) - в этом случае отображения адресов не требуется.Все групповые дейтаграммы IP передаются в исходном виде (as-is), включая локальное кадрирование.
Отображение для сетей других типов будет стандартизовано в будущем24.
Хостам рекомендуется обеспечивать для протоколов верхних уровней или приложений способ определения поддержки групповой адресации IP хостами подключенных сетей.
3.3.8 Сообщения об ошибках
На практике хосты должны возвращать сообщения ICMP об ошибках при обнаружении последних, за исключением тех случаев, когда возврат сообщений ICMP об ошибках специально запрещен.
Обсуждение:
Общим явлением в сетях на базе дейтаграмм является “болезнь черных дыр” (black hole disease) -дейтаграммы передаются адресату, а от того не приходит никаких откликов.При отсутствии откликов обнаружение проблем становится весьма затруднительным.
3.4 Интерфейс между IP и транспортным уровнем
Интерфейс между IP и транспортным уровнем должен обеспечивать полный доступ ко всем механизмам уровня IP, включая опции, тип обслуживания TOS и время жизни TTL. Транспортный уровень должен иметь механизм установки интерфейсных параметров или/и обеспечивать передачу таких параметров от приложений.
Обсуждение:
Для приложений очень важна возможность использования таких параметров, даже если соответствующие механизмы еще недостаточно эффективны в Internet (например, TOS).Реализация поддержки этих механизмов обеспечивает возможность работы с ними без серьезного изменения программных настроек хоста по мере реализации механизмов в Internet.
Опишем концептуальный интерфейс между транспортным уровнем и IP, как набор процедурных вызовов. Приведенное здесь описание является расширением RFC-791 [IP:1] (параграф 3.3).
♦ Передача дейтаграмм SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)
параметры процедуры описаны в RFC-791. Передача параметра Id необязательна (см. 3.2.1.5).
♦ Прием дейтаграмм
RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt)
Все параметры определены в RFC-791, за исключением SpecDest = указанный адрес получателя дейтаграммы (см. 3.2.1.3)
Полученный в результате параметр dst содержит адрес получателя дейтаграммы.Поскольку этот адрес может быть широковещательным, должен передаваться параметр SpecDest, не определенный в RFC-791.Параметр opt содержит все опции IP для дейтаграммы и также должен передаваться на транспортный уровень.
♦ Выбор адреса отправителя CET_SRCADDR(remote, TOS) -> local remote = remote IP address
TOS = тип обслуживания (Type-of-Service) local = локальный адрес IP См. параграф 3.3.4.3.
♦ Определение максимального размера дейтаграмм CET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
MMS_R = максимальный размер принимаемого сообщения транспортного уровня. MMS_S = максимальный размер передаваемого сообщения транспортного уровня. (local, remote, TOS определены выше) См. параграфы 3.3.2 и 3.3.3.
♦ Сообщение об успешной доставке
ADVISE_DELIVPROB(sense, local, remote, TOS)
Параметр sense представляет собой 1-битовый флаг, показывающий тип анонса (позитивный или негативный), описанного в параграфе 3.3.1.4. Остальные параметры были определены выше.
♦ Передача сообщения ICMP
24 См. RFC-1469 (Token Ring), RFC-2022 (ATM). Прим. перев. Перевод на русский язык - Н. Малых 31 rfc.com.ru
|
||
|
|
||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result
(Параметры определены в RFC-791).
Передача параметра Id не является обязательной (см. параграф 3.2.1.5). Транспортный уровень должен быть способен передавать некоторые сообщения ICMP - Port Unreachable или любой из запросов.Эта функция может рассматриваться как частный случай вызова SEND() и отдельное рассмотрение ее диктуется лишь задачами упрощения.
♦ Прием сообщения ICMP
RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
(Параметры определены в RFC-791).
Уровень IP должен передавать некоторые сообщения ICMP соответствующим программам транспортного уровня.Эта функция может рассматриваться как частный случай вызова RECV() и указана отдельно лишь для упрощения.
Для сообщений ICMP об ошибках, передаваемых на верхние уровни, данные должны включать исходный заголовок IP и все октеты исходной дейтаграммы, включенные в сообщение ICMP.Эти данные будут использоваться транспортным уровнем для поиска информации о состоянии соединения.
На верхний уровень передаются, в частности, следующие сообщения:
♦ Destination Unreachable
♦ Source Quench
♦ Echo Reply (пользовательскому интерфейсу ICMP, если Echo Request передан не с уровня IP)
♦ Timestamp Reply (пользовательскому интерфейсу ICMP)
♦ Time Exceeded
Обсуждение:
В будущем интерфейс обмена данными между транспортным уровнем и IP может быть расширен (см. параграф 3.3.1.3) для передачи информации о пути.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
3.5 Требования к уровню INTERNET
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
25 Только при реализации этой опции
Перевод на русский язык - Н. Малых 32 rfc.com.ru
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
26 Только при реализации опции
Перевод на русский язык - Н. Малых 33 rfc.com.ru
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
|||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||
|
27 Если опция реализована и включена.
28 Если не используются встроенные функции маршрутизатора или source routed.
Перевод на русский язык - Н. Малых 34 rfc.com.ru
|
|||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||
|
Robert Braden Requirements for Internet Hosts -- Communications Layers RFC-1122, октябрь 1989
|
|||||||||||||
|
|
|||||||||||||
|