RFC 1122 | Требования к интернет-хостам

Аннотация

Это один RFC из пары, который определяет и обсуждает требования к программному обеспечению хоста в Интернете. Этот RFC охватывает уровни протокола связи: канальный уровень, IP-уровень и транспортный уровень; его спутник RFC-1123 охватывает протоколы приложений и поддержки.
Скачать оригинальный документ на английском языке RFC 1122 PDF

1. Введение
1.1 Интернет-архитектура
1.1.1 Интернет-хосты
1.1.2 Архитектурные предположения
1.1.3 Набор Интернет-Протоколов
1.1.4 Код встроенного шлюза
1.2 Общие соображения
1.2.1 Продолжение интернет-эволюции
1.2.2 Принцип надежности
1.2.3 Регистрация ошибок
1.2.4 Конфигурация
1.3 Чтение этого документа
1.3.1 Организация
1.3.2 Требования
1.3.3 Терминология
1.4 Благодарности
2. Ссылочный слой
2.1 Введение
2.2 Протокол прохождения
2.3 Конкретные проблемы
2.3.1 Согласование протокола трейлера
2.3.2 Протокол разрешения адресов — ARP
2.3.2.1 Проверка ARP-кэша
2.3.2.2 ARP Packet Queue
2.3.3 Инкапсуляция Ethernet и IEEE 802
2.4 Интерфейс уровня Link / Internet
2.5 Сводная информация о требованиях канального уровня
3. Протоколы интернет-уровня
3.1 Введение
3.2 Протокол прохождения
3.2.1 Интернет-протокол — IP
3.2.1.1 Номер версии
3.2.1.2 Контрольная сумма
3.2.1.3 Адресация
3.2.1.4 Фрагментация и повторная сборка
3.2.1.5 Идентификация
3.2.1.6 Тип обслуживания
3.2.1.7 Время жизни
3.2.1.8 Опции
3.2.2 Протокол управляющих сообщений Интернета — ICMP
3.2.2.1 Место назначения недоступно
3.2.2.2 Перенаправление
3.2.2.3 Источник гасит
3.2.2.4 Превышено время
3.2.2.5 Проблема с параметрами
3.2.2.6 Эхо-запрос / ответ
3.2.2.7 Запрос информации / ответ
3.2.2.8 Отметка времени и ответ отметки времени
3.2.2.9 Адрес Маска Запрос / Ответ
3.2.3 Интернет-протокол управления группами IGMP
3.3 Конкретные проблемы
3.3.1 Маршрутизация исходящих дейтаграмм
3.3.1.1 Локальное / дистанционное решение
3.3.1.2 Выбор шлюза
3.3.1.3 Кэш-память маршрута
3.3.1.4 Обнаружение мертвого шлюза
3.3.1.5 Выбор нового шлюза
3.3.1.6 Инициализация
3.3.2 Сборка
3.3.3 Фрагментация
3.3.4 Локальное множественное возвращение
3.3.4.1 Введение
3.3.4.2 Требования к множественной адресации
3.3.4.3 Выбор адреса источника
3.3.5 Пересылка исходного маршрута
3.3.6 Трансляции
3.3.7 Многоадресная рассылка IP
3.3.8 Сообщение об ошибке
3.4 Интерфейс интернет / транспортного уровня
3.5 Сводка требований интернет-уровня
4. Транспортные протоколы
4.1 Протокол дейтаграмм пользователя — UDP
4.1.1 Введение
4.1.2 Прохождение протокола
4.1.3 Конкретные проблемы
4.1.3.1 Порты
4.1.3.2 Параметры IP
4.1.3.3 ICMP-сообщения
4.1.3.4 Контрольные суммы UDP
4.1.3.5 UDP Multihoming
4.1.3.6 Неверные адреса
4.1.4 Интерфейс уровня UDP / APPLICATION
4.1.5 Сводка требований UDP
4.2 Протокол управления передачей — TCP
4.2.1 Введение
4.2.2 Прохождение протокола
4.2.2.1. Известные порты
4.2.2.2 Использование Push
4.2.2.3 Размер окна
4.2.2.4 Срочный указатель
4.2.2.5 Параметры TCP
4.2.2.6 Опция максимального размера сегмента
4.2.2.7 Контрольная сумма TCP
4.2.2.8 Диаграмма состояния соединения TCP
4.2.2.9 Выбор начального порядкового номера
4.2.2.10 Одновременные открытые попытки
4.2.2.11 Восстановление из старого дубликата SYN
4.2.2.12 Сегмент RST
4.2.2.13 Закрытие соединения
4.2.2.14 Передача данных
4.2.2.15 Время ожидания повторной передачи
4.2.2.16 Управление окном
4.2.2.17 Зондирование нулевых окон
4.2.2.18 Пассивные вызовы OPEN
4.2.2.19 Время жить
4.2.2.20 Обработка событий
4.2.2.21. Подтверждение сегментов в очереди
4.2.3 Конкретные проблемы
4.2.3.1 Расчет времени ожидания повторной передачи
4.2.3.2 Когда отправлять сегмент ACK
4.2.3.3 Когда отправлять обновление окна
4.2.3.4 Когда отправлять данные
4.2.3.5 Сбои соединения TCP
4.2.3.6 TCP Keep-Alives
4.2.3.7 TCP Multihoming
4.2.3.8 Опции IP
4.2.3.9 ICMP-сообщения
4.2.3.10 Удаленная проверка адреса
4.2.3.11. Шаблоны трафика TCP
4.2.3.12 Эффективность
4.2.4 Интерфейс уровня TCP / APPLICATION
4.2.4.1 Асинхронные отчеты
4.2.4.2 Тип обслуживания
4.2.4.3 Промывочный звонок
4.2.4.4 Multihoming
4.2.5 Сводка требований TCP
5. Ссылки

Статус этой заметки

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

1. Введение

Этот документ является одним из пары, которая определяет и обсуждает требования для реализаций хост-системы пакета интернет-протоколов. Этот RFC охватывает уровни протокола связи: канальный уровень, IP-уровень и транспортный уровень. Его сопутствующий RFC «Требования к хостам в Интернете — применение и поддержка» [INTRO: 1] охватывает протоколы прикладного уровня. Этот документ также следует читать вместе с «Требованиями к интернет-шлюзам» [INTRO: 2].

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

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

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

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

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

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

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

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

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

1.1 Интернет-архитектура

Общий фон и обсуждение архитектуры Интернета и вспомогательного набора протоколов можно найти в Справочнике по протоколу DDN [INTRO: 3]; для справки см., например, [INTRO: 9], [INTRO: 10] и [INTRO: 11]. Ссылка [INTRO: 5] описывает процедуру получения документов интернет-протокола, в то время как [INTRO: 6] содержит список номеров, назначенных в интернет-протоколах.

1.1.1 Интернет-хосты

Хост-компьютер, или просто «хост», является конечным потребителем услуг связи. Хост обычно выполняет прикладные программы от имени пользователя (ей), используя сетевые и / или интернет-службы связи для поддержки этой функции. Интернет-хост соответствует концепции «конечной системы», используемой в наборе протоколов OSI [INTRO: 13].

Система Интернет-связи состоит из взаимосвязанных пакетных сетей, поддерживающих связь между хост-компьютерами с использованием интернет-протоколов. Сети соединены между собой с помощью компьютеров с коммутацией пакетов, которые интернет-сообщество называет «шлюзами» или «IP-маршрутизаторами», а «OSI» — средой OSI [INTRO: 13]. RFC «Требования к интернет-шлюзам» [INTRO: 2] содержит официальные спецификации для интернет-шлюзов. Этот RFC вместе с настоящим документом и его компаньоном [INTRO: 1] определяют правила текущей реализации архитектуры Интернета.

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

Обычно говорят, что хост является много-сетевым, если он имеет более одного интерфейса для одной и той же или для разных сетей. См. Раздел 1.1.3 «Терминология».

1.1.2 Архитектурные предположения

Современная интернет-архитектура основана на ряде предположений о системе связи. Предположения, наиболее подходящие для хостов, следующие:

(а) Интернет — это сеть сетей

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

(b) Шлюзы не хранят информацию о состоянии соединения

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

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

(c) Сложность маршрутизации должна быть в шлюзах

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

(d) Система должна допускать широкую вариацию сети

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

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

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

1.1.3 Интернет-протокол

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

Уровни протокола, используемые в архитектуре Интернета, следующие [INTRO: 4]:

Прикладной уровень
Транспортный уровень
Интернет-Уровень
Канальный уровень

Прикладной уровень

Прикладной уровень является верхним уровнем набора протоколов Интернета. Интернет-пакет дополнительно не подразделяет прикладной уровень, хотя некоторые из протоколов интернет-уровня приложений содержат некоторые внутренние подуровни. Прикладной уровень интернет-пакета по существу объединяет функции двух верхних уровней — представления и приложения — эталонной модели OSI.

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

Наиболее распространенные пользовательские протоколы Интернета:

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

Существует ряд других стандартизированных пользовательских протоколов [INTRO: 4] и множество частных пользовательских протоколов.

Протоколы поддержки, используемые для сопоставления имен хостов, загрузки и управления, включают протоколы SNMP, BOOTP, RARP и DNS.

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

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

Протокол управления передачей (TCP)
Протокол пользовательских дейтаграмм (UDP)

TCP — это надежный транспортный сервис, ориентированный на соединение, который обеспечивает сквозную надежность, повторное упорядочение и управление потоком. UDP является транспортной службой без установления соединения («датаграмма»).

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

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

Интернет-Уровень

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

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

Дейтаграмма или отсутствие соединения протокола IP является фундаментальной и характерной особенностью архитектуры Интернета. Интернет-IP был моделью для сетевого протокола OSI без установления соединения [INTRO: 12].

ICMP — это протокол управления, который считается неотъемлемой частью IP, хотя он архитектурно распределен по IP, то есть он использует IP для передачи своих данных в конец так же, как транспортный протокол, как TCP или UDP.

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

IGMP — это протокол уровня Интернета, используемый для создания динамических групп узлов для многоадресной рассылки IP.

Протоколы интернет-уровня IP, ICMP и IGMP обсуждаются в главе 3.

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

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

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

1.1.4 Код встроенного шлюза

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

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

В интернет-сообществе существуют различные мнения о функциональности встроенного шлюза. Основные аргументы таковы:

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

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

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

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

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

1.2 Общие соображения

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

1.2.1 Продолжение интернет-эволюции

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

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

1.2.2 Принцип надежности

На каждом уровне протоколов существует общее правило, применение которого может привести к огромным преимуществам в надежности и функциональной совместимости [IP: 1]:

Будьте либеральны в том, что вы принимаете, и консервативны в том, что вы отправляете

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

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

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

1.2.3 Регистрация ошибок

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

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

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

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

1.2.4 Конфигурация

Было бы идеально, если бы хост-реализация пакета интернет-протоколов могла полностью настраиваться самостоятельно. Это позволило бы реализовать весь комплект в ПЗУ или преобразовать в кремний, упростило бы бездисковые рабочие станции и стало бы огромным благом для обеспокоенных администраторов ЛВС, а также поставщиков систем. Мы не достигли этого идеала; на самом деле, мы даже не близко.

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

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

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

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

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

1.3 Чтение этого документа

1.3.1 Организация

Расслоение протокола, которое обычно используется в качестве организационного принципа при реализации сетевого программного обеспечения, также использовалось для организации этого документа. При описании правил мы предполагаем, что реализация строго отражает уровни протоколов. Таким образом, следующие три основных раздела определяют требования к канальному уровню, интернет-уровню и транспортному уровню соответственно. Сопутствующий RFC [INTRO: 1] охватывает программное обеспечение прикладного уровня. Эта слоистая организация была выбрана для простоты и ясности.

Однако строгая многоуровневая структура является несовершенной моделью как для набора протоколов, так и для рекомендуемых подходов к реализации. Протоколы на разных уровнях взаимодействуют сложным, а иногда и тонким образом, а отдельные функции часто включают несколько уровней. В реализации есть много вариантов дизайна, многие из которых включают в себя творческое «нарушение» строгого наслоения. Каждый разработчик должен прочитать ссылки [INTRO: 7] и [INTRO: 8].

В этом документе описывается концептуальный интерфейс службы между уровнями с использованием функциональной нотации («вызов процедуры»), подобной той, которая используется в спецификации TCP [TCP: 1]. Реализация хоста должна поддерживать логический поток информации, подразумеваемый этими вызовами, но не должна буквально реализовывать сами вызовы. Например, многие реализации отражают связь между транспортным уровнем и уровнем IP, предоставляя им общий доступ к общим структурам данных. Эти структуры данных, а не явные вызовы процедур, являются агентством для передачи большей части необходимой информации.

В целом каждый основной раздел этого документа состоит из следующих подразделов:

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

По многим отдельным темам в этом документе есть материал в скобках, помеченный как «ОБСУЖДЕНИЕ» или «ОСУЩЕСТВЛЕНИЕ». Данный материал предназначен для того, чтобы дать разъяснения и пояснения к предыдущему тексту требований. Он также включает в себя некоторые предложения о возможных будущих направлениях или событиях. Материал реализации содержит предложенные подходы, которые разработчик может пожелать рассмотреть.

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

1.3.2 Требования

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

Эти слова:

* «ОБЯЗАН» — Это слово или прилагательное «ТРЕБУЕТСЯ» означает, что предмет является абсолютным требованием спецификации.

* «ДОЛЖЕН» — Это слово или прилагательное «РЕКОМЕНДУЕТСЯ» означает, что могут существовать веские причины в определенных обстоятельствах игнорировать этот пункт, но следует понимать все последствия и тщательно взвесить случай, прежде чем выбрать другой курс.

* «МОЖЕТ» — Это слово или прилагательное «ДОПОЛНИТЕЛЬНО» означает, что этот пункт действительно необязателен. Один продавец может включить товар, потому что это требуется для конкретного рынка или, например, потому что он улучшает продукт; другой продавец может опустить этот же товар.

Реализация не соответствует требованиям, если она не удовлетворяет одному или нескольким требованиям MUST для протоколов, которые она реализует. Реализация, которая удовлетворяет всем требованиям MUST и всем ДОЛЖНЫМ для своих протоколов, называется «безусловно соответствующей»; тот, который удовлетворяет всем требованиям ОБЯЗАННО, но не всем ДОЛЖНЫМ требованиям для его протоколов, называется «условно совместимым».

1.3.3 Терминология

В этом документе используются следующие технические термины:

Segment — сегмент

Сегмент — это единица сквозной передачи в протоколе TCP. Сегмент состоит из заголовка TCP, за которым следуют данные приложения. Сегмент передается путем инкапсуляции внутри дейтаграммы IP.

Message — сообщение

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

IP Datagram — IP датаграмма

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

В описании интернет-уровня (раздел 3) следует понимать, что неквалифицированный термин «датаграмма» относится к дейтаграмме IP.

Packet — пакет

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

Frame — кадр

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

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

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

Multihomed

Узел называется многосетевым, если он имеет несколько IP-адресов. Обсуждение множественной адресации см. В разделе 3.3.4 ниже.

Physical network interface — Физический сетевой интерфейс

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

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

Мы определяем логический [сетевой] интерфейс как логический путь, отличающийся уникальным IP-адресом, к подключенной сети. См. Раздел 3.3.4.

Specific-destination address — Конкретный адрес назначения

Это эффективный адрес назначения дейтаграммы, даже если она широковещательная или многоадресная; см. раздел 3.2.1.3.

Path — путь

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

MTU

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

Термины кадр, пакет, датаграмма, сообщение и сегмент иллюстрируются следующими схематическими диаграммами:

А. Передача по подключенной сети:

B. До фрагментации IP или после повторной сборки IP:

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

Этот документ включает в себя вклады и комментарии большой группы экспертов по интернет-протоколам, включая представителей университетских и исследовательских лабораторий, поставщиков и государственных учреждений. Он был собран в основном Рабочей группой по требованиям к хостам Инженерной рабочей группы по Интернету (IETF).

Редактор особенно хотел бы отметить неустанную преданность следующих людей, которые посетили много долгих собраний и сгенерировали 3 миллиона байтов электронной почты за последние 18 месяцев в поисках этого документа: Филипп Алмквист, Дейв Борман (Cray Research), Ноэль Чьяппа, Дейв Крокер (DEC), Стив Диринг (Стэнфорд), Майк Карелс (Беркли), Фил Карн (Bellcore), Джон Лекашман (NASA), Чарльз Линн (BBN), Кит МакКлогри (TWG), Пол Мокапетрис (ISI), Томас Нартен (Пердью), Крейг Партридж (BBN), Дрю Перкинс (CMU) и Джеймс Ван Боккелен (FTP Software).

Кроме того, следующие люди внесли большой вклад в эту работу: Билл Барнс (Митра), Стив Белловин (AT & T), Майк Брешиа (BBN), Эд Каин (DCA), Аннет ДеШон (ISI), Мартин Гросс (DCA), Фил Гросс (NRI), Чарльз Хедрик (Ратгерс), Ван Якобсон (LBL), Джон Кленсин (MIT), Марк Лоттор (SRI), Мило Медин (NASA), Билл Мелон (Sun Microsystems), Грег Миншалл (кинетика), Джефф Могул (DEC), Джон Маллен (CMC), Джон Постел (ISI), Джон Ромки (Epilogue Technology) и Майк Стжонс (DCA). Следующие также внесли значительный вклад в конкретные области: Эрик Аллман (Беркли), Роб Остин (MIT), Арт Берггрин (ACC), Кит Бостик (Беркли), Винт Серф (NRI), Уэйн Хэтэуэй (NASA), Мэтт Корн (IBM ), Эрик Наггум (Naggum Software, Норвегия), Роберт Уллманн (Prime Computer), Дэвид Вайцман (BBN), Фрэнк Ванчо (США), Арун Уэлч (штат Огайо), Билл Вестфилд (Cisco) и Райан Захариассен (Торонто).

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

2. Канальный уровень — Link layer

Все интернет-системы, как хосты, так и шлюзы, предъявляют одинаковые требования к протоколам канального уровня. Эти требования приведены в главе 3 «Требования к интернет-шлюзам» [INTRO: 2], дополненной материалами этого раздела.

2.1 Введение

2.2 Протокол прохождения

Ничего

2.3 Конкретные проблемы

2.3.1 Согласование протокола трейлера

Протокол трейлера [LINK: 1] для инкапсуляции на канальном уровне МОЖЕТ использоваться, но только в том случае, если проверено, что обе системы (хост или шлюз), участвующие в связи на канальном уровне, реализуют трейлеры. Если система динамически не согласовывает использование протокола трейлера для каждого пункта назначения, конфигурация по умолчанию ДОЛЖНА отключить протокол.

DISCUSSION — Обсуждение

Протокол трейлера — это метод инкапсуляции канального уровня, который переупорядочивает содержимое данных пакетов, отправляемых в физической сети. В некоторых случаях трейлеры улучшают пропускную способность протоколов более высокого уровня, уменьшая объем копирования данных в операционной системе. Протоколы более высокого уровня не знают об использовании трейлера, но хост-отправитель и получатель ДОЛЖНЫ понимать протокол, если он используется.

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

IMPLEMENTATION — Реализация

В Ethernet пакеты