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]:

1. Прикладной уровень
2. Транспортный уровень
3. Интернет-Уровень
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, предоставляя им общий доступ к общим структурам данных. Эти структуры данных, а не явные вызовы процедур, являются агентством для передачи большей части необходимой информации.

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

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

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

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

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

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

Ничего

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

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

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

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

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

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

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

В Ethernet пакеты, инкапсулированные в трейлеры, используют отдельный тип Ethernet [LINK: 1], и согласование трейлера выполняется в то время, когда ARP используется для обнаружения адреса канального уровня системы назначения.

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

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

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

2.3.2 Протокол разрешения адресов — Address Resolution Protocol (ARP)

2.3.2.1 Проверка ARP-кэша

Реализация протокола разрешения адресов (ARP) [LINK: 2] ДОЛЖНА обеспечивать механизм для очистки устаревших записей кэша. Если в этом механизме используется тайм-аут, ДОЛЖНО быть возможно настроить значение тайм-аута.

НЕОБХОДИМО, чтобы механизм предотвращения затопления ARP (повторная отправка запроса ARP для одного и того же IP-адреса с высокой скоростью). Рекомендуемая максимальная скорость составляет 1 в секунду на пункт назначения.

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

Спецификация ARP [LINK: 2] предлагает, но не требует механизма тайм-аута для аннулирования записей кэша, когда хосты изменяют свои адреса Ethernet. Распространенность прокси-ARP (см. Раздел 2.4 [INTRO: 2]) значительно увеличила вероятность того, что записи кэша в хостах станут недействительными, и поэтому для хостов теперь требуется некоторый механизм аннулирования ARP-кэша. Даже в отсутствие прокси-ARP длительный тайм-аут кэширования полезен для автоматического исправления любых неверных данных ARP, которые могли быть кэшированы.

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

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

1. Тайм-аут — Периодически тайм-аут записей в кэше, даже если они используются. Обратите внимание, что этот тайм-аут должен быть перезапущен, когда запись в кэше «обновлена» (путем наблюдения полей источника, независимо от целевого адреса, трансляции ARP от рассматриваемой системы). Для ситуаций прокси ARP время ожидания должно быть порядка минуты.
2. Одноадресный опрос — Активно опрашивает удаленный хост, периодически отправляя ему двухточечный запрос ARP, и удаляет запись, если от N последовательных опросов не получен ответ ARP. Опять же, время ожидания должно быть порядка минуты, и обычно N равно 2.
3. Рекомендация канального уровня — если драйвер канального уровня обнаруживает проблему доставки, очистите соответствующую запись кэша ARP.
4. Консультация более высокого уровня — Обеспечение вызова с Интернет-уровня на канальный уровень для индикации проблемы доставки. Результатом этого вызова будет аннулирование соответствующей записи в кэше. Этот вызов будет аналогичен вызову «ADVISE_DELIVPROB ()» от транспортного уровня до уровня Интернета (см. Раздел 3.4), и фактически процедура ADVISE_DELIVPROB, в свою очередь, может вызвать процедуру рекомендации уровня канала, чтобы сделать недействительной запись в кэше ARP.

Подходы (1) и (2) включают тайм-ауты ARP-кэша порядка минуты или меньше. В отсутствие прокси-ARP такой короткий тайм-аут может создать заметный служебный трафик в очень большой сети Ethernet. Поэтому может потребоваться настроить хост для увеличения времени ожидания кэша ARP.

2.3.2.2 ARP Packet Queue

Канальный уровень ДОЛЖЕН сохранять (а не отбрасывать) по меньшей мере один (самый последний) пакет из каждого набора пакетов, предназначенных для одного и того же неразрешенного IP-адреса, и передавать сохраненный пакет, когда адрес был разрешен.

Обсуждение:

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

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].

Каждый интернет-хост подключен к кабелю Ethernet 10 Мбит / с:

• ДОЛЖЕН иметь возможность отправлять и получать пакеты, используя инкапсуляцию RFC-894;
• ДОЛЖЕН иметь возможность принимать пакеты RFC-1042, смешанные с пакетами RFC-894; а также
• МОЖЕТ иметь возможность отправлять пакеты, используя инкапсуляцию RFC-1042.

Узел Интернета, который реализует отправку как инкапсуляций RFC-894, так и RFC-1042, ДОЛЖЕН предоставить переключатель конфигурации для выбора отправляемого, и этот переключатель ДОЛЖЕН по умолчанию установить RFC-894.

Обратите внимание, что стандартная инкапсуляция IP в RFC-1042 не использует значение идентификатора протокола (K1 = 6), которое IEEE зарезервировано для IP; вместо этого он использует значение (K1 = 170), которое подразумевает расширение («SNAP»), которое можно использовать для хранения поля Ether-Type. Интернет-система НЕ ДОЛЖНА отправлять 802 пакета, используя K1 = 6.

Трансляция адресов из интернет-адресов в адреса канального уровня в сетях Ethernet и IEEE 802 ДОЛЖНА управляться протоколом разрешения адресов (ARP).

MTU для Ethernet составляет 1500, а для 802.3 — 1492.

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

Спецификация IEEE 802.3 предусматривает работу по кабелю Ethernet 10 Мбит / с, в этом случае кадры Ethernet и IEEE 802.3 могут физически смешиваться. Приемник может различать кадры Ethernet и 802.3 по значению поля длины 802.3; это двухоктетное поле в заголовке совпадает с полем Ether-Type кадра Ethernet. В частности, поле длины 802.3 должно быть меньше или равно 1500, тогда как все действительные значения типа Ether больше 1500.

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

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

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

2.4 Интерфейс уровня Link / Internet

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

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

Хотя IP-уровень обычно не знает адресов канального уровня (поскольку каждый другой сетевой носитель обычно имеет свой формат адреса), широковещательный адрес на широковещательной среде является важным частным случаем. См. Раздел 3.2.2, особенно ОБСУЖДЕНИЕ, касающееся широковещательных штормов.

 

Интерфейс передачи пакетов между уровнями IP и канала связи ДОЛЖЕН включать 5-битовое поле TOS (см. Раздел 3.2.1.6).

Канальный уровень НЕ ДОЛЖЕН сообщать об IP-адресе об ошибке, связанной с недоступностью пункта назначения, исключительно потому, что для пункта назначения отсутствует запись в кэше ARP.

2.5 Сводная информация о требованиях канального уровня

Инкапсуляция трейлера (MAY — возможно)

Отправка трейлеров по умолчанию без согласования (MUST NOT — не обязан)

ARP

Очистить устаревшие записи кэша ARP (MUST — обязан)

Предотвратить ARP-наводнения (MUST — обязан)

Тайм-аут кэша настраивается (SHOULD — должен)

Сохранить хотя бы один (последний) неразрешенный pkt (SHOULD — должен)

Инкапсуляция Ethernet и IEEE 802
Хозяин способен:

Отправка и получение инкапсуляции RFC-894 (MUST — обязан)

Получите инкапсуляцию RFC-1042 (SHOULD — должен)

Отправить инкапсуляцию RFC-1042 (MAY — возможно)

Тогда конфиг. юго-запад выбрать, RFC-894 dflt (MUST — обязан)

Отправить K1 = 6 инкапсуляцию (MUST NOT — не обязан)

Используйте ARP в сетях Ethernet и IEEE 802 (MUST — обязан)

Отчет уровня канала b’casts на уровень IP (MUST — обязан)

Уровень IP передает TOS на канальный уровень (MUST — обязан)

Нет записи кэша ARP, рассматриваемой как Dest. Unreach. (MUST NOT — не обязан)

 

3. Протоколы интернет-уровня

3.1 Введение

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

Стандарты протокола, используемые на уровне Интернета:

• RFC-791 [IP: 1] определяет протокол IP и дает представление об архитектуре Интернета.
• RFC-792 [IP: 2] определяет ICMP, который обеспечивает маршрутизацию, диагностику и функциональность ошибок для IP. Хотя сообщения ICMP инкапсулированы в дейтаграммы IP, обработка ICMP считается (и обычно реализуется как) частью уровня IP. Смотри раздел 3.2.2.
• RFC-950 [IP: 3] определяет обязательное расширение подсети для архитектуры адресации.
• RFC-1112 [IP: 4] определяет IGMP по протоколу управления группами Интернета как часть рекомендуемого расширения для узлов и интерфейса хост-шлюз для поддержки многоадресной рассылки в Интернете на уровне IP. См. Раздел 3.2.3.
  Целью многоадресной IP-рассылки может быть произвольная группа интернет-хостов. Многоадресная IP-рассылка разработана как естественное расширение средств многоадресной рассылки на канальном уровне некоторых сетей и предоставляет стандартные средства для локального доступа к таким средствам многоадресной рассылки на канальном уровне.

Другие важные ссылки перечислены в разделе 5 этого документа.

Интернет-уровень программного обеспечения хоста ДОЛЖЕН реализовывать как IP, так и ICMP. Требования к поддержке IGMP приведены в разделе 3.3.7.

Уровень IP хоста имеет две основные функции: (1) выбрать шлюз «следующего перехода» или хост для исходящих IP-дейтаграмм и (2) повторно собрать входящие IP-дейтаграммы. Уровень IP также может (3) осуществлять преднамеренную фрагментацию исходящих дейтаграмм. Наконец, уровень IP должен (4) обеспечивать функциональность диагностики и ошибок. Мы ожидаем, что функции уровня IP могут в будущем несколько расшириться, поскольку будут разработаны дополнительные средства контроля и управления Интернетом.

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

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

Для исходящих дейтаграмм уровень IP:

1. устанавливает любые поля, не установленные транспортным уровнем;
2. выбирает правильный первый прыжок в подключенной сети (процесс, называемый «маршрутизацией»);
3. фрагментирует дейтаграмму, если необходимо, и если осуществляется преднамеренная фрагментация (см. Раздел 3.3.3); а также
4. передает пакет (ы) соответствующему драйверу канального уровня.

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

1. Локальная множественная адресация — сам хост является многосетевым; или же
2. Удаленная множественная адресация — локальный хост должен обмениваться данными с удаленным многосетевым хостом.

В настоящее время удаленная множественная адресация ДОЛЖНА обрабатываться на прикладном уровне, как обсуждалось в сопроводительном документе RFC [INTRO: 1]. Хост МОЖЕТ поддерживать локальную множественную адресацию, которая обсуждается в этом документе, и в частности в разделе 3.3.4.

Любой хост, который пересылает дейтаграммы, сгенерированные другим хостом, действует как шлюз и ДОЛЖЕН также соответствовать спецификациям, изложенным в требованиях к шлюзу RFC [INTRO: 2]. Интернет-хост, который включает встроенный код шлюза, ДОЛЖЕН иметь переключатель конфигурации, чтобы отключить функцию шлюза, и этот переключатель ДОЛЖЕН по умолчанию работать в режиме без шлюза. В этом режиме дейтаграмма, поступающая через один интерфейс, не будет пересылаться на другой хост или шлюз (если он не маршрутизируется от источника), независимо от того, является ли хост однодомным или многосетевым. Программное обеспечение хоста НЕ ДОЛЖНО автоматически переходить в режим шлюза, если хост имеет более одного интерфейса, так как оператор машины может не захотеть предоставлять эту услугу или быть компетентным для этого.

Далее в некоторых случаях указывается действие, которое «молча отбрасывает» принятую дейтаграмму. Это означает, что дейтаграмма будет отброшена без дальнейшей обработки и что в результате хост не отправит сообщение об ошибке ICMP (см. Раздел 3.2.2). Однако для диагностики проблем хост ДОЛЖЕН предоставить возможность регистрации ошибки (см. Раздел 1.2.3), включая содержимое молчащей дейтаграммы, и ДОЛЖЕН записать событие в счетчике статистики.

Обсуждение:

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

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

3.2.1 Интернет-протокол — IP

3.2.1.1 Номер версии (RFC-791 Section 3.1)

Дейтаграмма, номер версии которой не равен 4, ДОЛЖНА быть отброшена без предупреждения.

3.2.1.2 Контрольная сумма (RFC-791 Section 3.1)

Хост ДОЛЖЕН проверять контрольную сумму заголовка IP на каждой полученной дейтаграмме и молча отбрасывать каждую дейтаграмму, имеющую неверную контрольную сумму.

3.2.1.3 Адресация (RFC-791 Section 3.2)

В настоящее время существует пять классов IP-адресов: от класса A до класса E. Адреса класса D используются для многоадресной рассылки IP [IP: 4], в то время как адреса класса E зарезервированы для экспериментального использования.

Адрес многоадресной передачи (класс D) — это 28-разрядный логический адрес, который обозначает группу хостов и может быть постоянным или временным. Постоянные адреса многоадресной рассылки распределяются Органом по присвоению номеров в Интернете [INTRO: 6], в то время как временные адреса могут динамически назначаться группам переходных процессов. Членство в группах определяется динамически с использованием IGMP [IP: 4].

Теперь мы суммируем важные частные случаи для IP-адресов классов A, B и C, используя следующие обозначения для IP-адреса:

{ <Network-number>, <Host-number> } или { <Network-number>, <Subnet-number>, <Host-number> }

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

(а) {0, 0}

Этот хост в этой сети. НЕ ДОЛЖЕН отправляться, кроме как в качестве адреса источника как части процедуры инициализации, с помощью которой хост узнает свой собственный IP-адрес.

См. Также раздел 3.3.6 для нестандартного использования {0,0}.

(b) {0, <номер хоста>}
Указанный хост в этой сети. Он НЕ ДОЛЖЕН отправляться, кроме как в качестве адреса источника как части процедуры инициализации, с помощью которой хост узнает свой полный IP-адрес.

(с) {-1, -1}
Ограниченная трансляция. Он НЕ ДОЛЖЕН использоваться в качестве адреса источника.
Датаграмма с этим адресом назначения будет приниматься каждым узлом в подключенной физической сети, но не будет пересылаться за пределы этой сети.

(d) {<номер сети>, -1}
Направленная трансляция в указанную сеть. Он НЕ ДОЛЖЕН использоваться в качестве адреса источника.

(e) {<номер сети>, <номер подсети>, -1}
Направленная трансляция в указанную подсеть. Он НЕ ДОЛЖЕН использоваться в качестве адреса источника.

(f) {<номер сети>, -1, -1}
Направленная широковещательная рассылка во все подсети указанной подсети. Он НЕ ДОЛЖЕН использоваться в качестве адреса источника.

(g) {127, <любой>}
Внутренний адрес обратной связи хоста. Адреса этой формы НЕ ДОЛЖНЫ появляться вне хоста.

 

<Network-number> назначается административно, поэтому его значение будет уникальным во всем мире.

IP-адресам не разрешается иметь значение 0 или -1 для любого из полей <Host-number>, <Network-number> или <Subnetnumber> (кроме особых случаев, перечисленных выше). Это подразумевает, что каждое из этих полей будет иметь длину не менее двух битов.

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

Хост ДОЛЖЕН поддерживать расширения подсети для IP [IP: 3]. В результате будет маска адреса в форме: {-1, -1, 0}, связанная с каждым из локальных IP-адресов хоста; см. разделы 3.2.2.9 и 3.3.1.1.

Когда хост отправляет любую дейтаграмму, IP-адрес источника ДОЛЖЕН быть одним из его собственных IP-адресов (но не широковещательным или многоадресным адресом).
Хост ДОЛЖЕН молча отбрасывать входящую дейтаграмму, которая не предназначена для хоста. Входящая дейтаграмма предназначена для хоста, если поле адреса назначения дейтаграммы:

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

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

Хост ДОЛЖЕН молча отбрасывать входящую дейтаграмму, содержащую IP-адрес источника, который недопустим по правилам этого раздела. Эта проверка может быть выполнена либо на уровне IP, либо с помощью каждого протокола на транспортном уровне.

Обсуждение:

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

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

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

3.2.1.4 Фрагментация и повторная сборка (RFC-791 Section 3.2)

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

3.2.1.5 Идентификация (RFC-791 Section 3.2)

При отправке идентичной копии более ранней дейтаграммы хост МОЖЕТ при желании сохранить то же поле идентификации в копии.

Обсуждение:

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

Однако наблюдаемые закономерности потери дейтаграмм в Интернете не способствуют вероятности повторной передачи фрагментов, заполняющих пробелы в повторной сборке, в то время как другие механизмы (например, повторная упаковка TCP при повторной передаче) имеют тенденцию предотвращать повторную передачу идентичной дейтаграммы [IP: 9]. Поэтому мы считаем, что повторная передача одного и того же поля идентификации не является полезной. Кроме того, транспортный протокол без установления соединения, такой как UDP, потребовал бы взаимодействия прикладных программ для сохранения одного и того же значения идентификации в идентичных дейтаграммах.

3.2.1.6 Тип обслуживания (RFC-791 Section 3.2)

Байт «Тип обслуживания» в заголовке IP разделен на два раздела: поле «Precedence» (старшие 3 бита) и поле, которое обычно называется «тип обслуживания» или «TOS» (низкий уровень). -заказ 5 бит). В этом документе все ссылки на «TOS» или «поле TOS» относятся только к младшим 5 битам.

Поле Precedence предназначено для приложений Министерства обороны по протоколам Интернета. Использование ненулевых значений в этом поле выходит за рамки этого документа и спецификации стандарта IP. Поставщики должны проконсультироваться с Агентством связи по обороне (DCA) для получения инструкций по полю IP Precedence и его последствиям для других протокольных уровней. Однако поставщики должны учитывать, что использование приоритета, скорее всего, потребует, чтобы его значение передавалось между уровнями протокола точно так же, как передается поле TOS.

Уровень IP ДОЛЖЕН обеспечивать средство для транспортного уровня для установки поля TOS каждой отправляемой дейтаграммы; по умолчанию все нулевые биты. Уровень IP ДОЛЖЕН передавать принятые значения TOS на транспортный уровень.

Конкретные отображения TOS на канальном уровне, содержащиеся в RFC-795, НЕ ДОЛЖНЫ быть реализованы.

Обсуждение:

Хотя область TOS в прошлом использовалась мало, ожидается, что в ближайшем будущем она будет играть все большую роль. Предполагается, что поле TOS будет использоваться для управления двумя аспектами операций шлюза: алгоритмами маршрутизации и организации очередей. См. Раздел 2 [INTRO: 1] для требований к прикладным программам для определения значений TOS.

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

3.2.1.7 Время жизни (RFC-791 Section 3.2)

Хост НЕ ДОЛЖЕН отправлять дейтаграмму со значением времени жизни (TTL), равным нулю.

Хост НЕ ДОЛЖЕН сбрасывать дейтаграмму только потому, что она была получена с TTL меньше 2.

Уровень IP ДОЛЖЕН обеспечивать средство для транспортного уровня для установки поля TTL каждой отправляемой дейтаграммы. Когда используется фиксированное значение TTL, оно ДОЛЖНО быть настраиваемым. Текущее предлагаемое значение будет опубликовано в RFC «Назначенные номера».

Обсуждение:

Поле TTL имеет две функции: ограничивать время жизни сегментов TCP (см. RFC-793 [TCP: 1], стр. 28) и завершать циклы интернет-маршрутизации. Хотя TTL — это время в секундах, у него также есть некоторые атрибуты количества переходов, поскольку каждый шлюз должен уменьшить поле TTL как минимум на единицу.

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

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

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

3.2.1.8 Опции

Для транспортного уровня ДОЛЖНЫ быть средства для определения параметров 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. Хосты, отправляющие несколько опций, должны знать, что это вносит двусмысленность в значение определенных опций в сочетании с опцией source-route.

РЕАЛИЗАЦИЯ:

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

Вот требования к конкретным параметрам IP:

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

В некоторых средах требуется опция безопасности в каждой датаграмме; такое требование выходит за рамки этого документа и спецификации стандарта IP. Однако обратите внимание, что параметры безопасности, описанные в RFC-791 и RFC-1038, устарели. Для приложений DoD поставщики должны консультироваться с [IP: 8] для руководства.

(б) Опция идентификатора потока

Эта опция устарела; оно НЕ ДОЛЖНО быть отправлено, и оно ДОЛЖНО быть молча проигнорировано, если получено.

(c) Параметры исходного маршрута

Хост ДОЛЖЕН поддерживать исходный маршрут источника и ДОЛЖЕН быть в состоянии действовать как конечный пункт назначения исходного маршрута.

Если хост получает дейтаграмму, содержащую завершенный исходный маршрут (то есть указатель указывает за последнее поле), дейтаграмма достигла своего конечного пункта назначения; опция как получено (записанный маршрут) ДОЛЖНА быть передана на транспортный уровень (или к обработке сообщений ICMP). Этот записанный маршрут будет перевернут и использован для формирования исходного маршрута для ответных дейтаграмм (см. Обсуждение опций IP в разделе 4). Когда маршрут обратного источника построен, он ДОЛЖЕН быть правильно сформирован, даже если записанный маршрут включает исходный хост (см. Случай (B) в обсуждении ниже).

НЕ ДОЛЖЕН отправляться заголовок IP, содержащий более одной опции исходного маршрута; влияние на маршрутизацию нескольких опций Source Route зависит от конкретной реализации.

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

Обсуждение:

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

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

(A): {>>G2, G3, … Gn, D} <— CORRECT
(B): {S, >>G2, G3, … Gn, D} <—- WRONG

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

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

Реализация создания и обработки опции Record Route является необязательной.

(e) Опция Timestamp

Реализация создания и обработки опции Timestamp НЕОБЯЗАТЕЛЬНА. Если это реализовано, применяются следующие правила:

• Исходный хост ДОЛЖЕН записывать временную метку в параметре Timestamp, чьи поля интернет-адресов не указаны заранее или чей первый предварительно указанный адрес является адресом интерфейса хоста.
• Хост назначения ДОЛЖЕН (если возможно) добавить текущую временную метку в параметр Timestamp, прежде чем передать параметр на транспортный уровень или в ICMP для обработки.
• Значение временной метки ДОЛЖНО соответствовать правилам, приведенным в разделе 3.2.2.8 для сообщения временной метки ICMP.

3.2.2 Протокол управляющих сообщений Интернета — ICMP

Сообщения ICMP сгруппированы в два класса.

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

• Пункт назначения недоступен (см. Раздел 3.2.2.1)
• Перенаправление (см. Раздел 3.2.2.2)
• Источник гасит (см. Раздел 3.2.2.3)
• Превышено время (см. Раздел 3.2.2.4)
• Проблема с параметрами (см. Раздел 3.2.2.5)

ICMP-сообщения с запросами:

• Эхо (см. Раздел 3.2.2.6)
• Информация (см. Раздел 3.2.2.7)
• Отметка времени (см. Раздел 3.2.2.8)
• Адресная маска (см. Раздел 3.2.2.9)

Если получено сообщение ICMP неизвестного типа, оно ДОЛЖНО быть отброшено без уведомления.

Каждое сообщение об ошибке ICMP включает заголовок Интернета и, по крайней мере, первые 8 октетов данных дейтаграммы, которая вызвала ошибку; МОЖЕТ быть отправлено более 8 октетов; этот заголовок и данные ДОЛЖНЫ быть неизменными из полученной дейтаграммы.

В тех случаях, когда требуется, чтобы интернет-уровень передавал сообщение об ошибке ICMP на транспортный уровень, номер IP-протокола ДОЛЖЕН быть извлечен из исходного заголовка и использован для выбора соответствующего объекта транспортного протокола для обработки ошибки.

Сообщение об ошибке ICMP ДОЛЖНО быть отправлено с обычными (т.е. нулевыми) битами TOS.

Сообщение об ошибке ICMP НЕ ДОЛЖНО отправляться в результате получения:

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

ПРИМЕЧАНИЕ: ЭТИ ОГРАНИЧЕНИЯ ПРИНИМАЮТСЯ НАД ЛЮБОЙ ТРЕБОВАНИЕЮ В ЭТОМ ДОКУМЕНТЕ ДЛЯ ОТПРАВКИ СООБЩЕНИЙ ОБ ОШИБКАХ ICMP.

Обсуждение:

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

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

РЕАЛИЗАЦИЯ:

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

3.2.2.1 Место назначения недоступно

Следующие дополнительные коды определены ниже:

• 6 = сеть назначения неизвестна
• 7 = хост назначения неизвестен
• 8 = исходный хост изолирован
• 9 = связь с сетью назначения административно запрещена
• 10 = связь с хостом назначения административно запрещена
• 11 = сеть недоступна для типа услуги
• 12 = хост недоступен для типа услуги

Хост ДОЛЖЕН генерировать сообщения о недостижимости получателя с кодом:

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

Полученное сообщение о недоступности назначения ДОЛЖНО быть сообщено на транспортный уровень. Транспортный уровень ДОЛЖЕН использовать информацию надлежащим образом; например, см. разделы 4.1.3.3, 4.2.3.9 и 4.2.4 ниже. Транспортный протокол, который имеет свой собственный механизм для уведомления отправителя о том, что порт недоступен (например, TCP, который отправляет сегменты RST), ДОЛЖЕН, тем не менее, принять порт ICMP, недоступный для той же цели.

Сообщение о недоступности пункта назначения, полученное с кодом 0 (нетто), 1 (хост) или 5 (неверный маршрут источника), может быть результатом переходного процесса маршрутизации и поэтому ДОЛЖНО интерпретироваться как только подсказка, а не доказательство того, что указанный пункт назначения является недоступен [IP: 11]. Например, он НЕ ДОЛЖЕН использоваться в качестве доказательства мертвого шлюза (см. Раздел 3.3.1).

3.2.2.2 Перенаправление

Хосту НЕ СЛЕДУЕТ отправлять сообщение ICMP Redirect; Перенаправления должны отправляться только шлюзами.

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

Сообщение перенаправления СЛЕДУЕТ молча отбрасывать, если указанный адрес нового шлюза находится не в той же подключенной (подсетевой) сети, через которую поступило перенаправление [INTRO: 2, Приложение A], или если источник перенаправления не является текущим шлюз первого перехода для указанного пункта назначения (см. раздел 3.3.1).

3.2.2.3 Источник гасит

Хост МОЖЕТ послать сообщение Source Quench, если оно приближается или достигло точки, в которой оно вынуждено отбрасывать входящие дейтаграммы из-за нехватки буферов повторной сборки или других ресурсов. См. Раздел 2.2.3 [INTRO: 2] для предложений о том, когда отправлять Source Quench.

Если получено сообщение Source Quench, IP-уровень ДОЛЖЕН сообщить об этом транспортному уровню (или обработке ICMP). Как правило, транспортный или прикладной уровень ДОЛЖЕН реализовать механизм ответа на запрос источника для любого протокола, который может отправлять последовательность дейтаграмм в одно и то же место назначения и который, как можно разумно ожидать, будет поддерживать достаточно информации о состоянии, чтобы сделать это возможным. См. Раздел 4 для обработки Source Quench по TCP и UDP.

Обсуждение:

Обработка источника может быть сгенерирована целевым хостом или некоторым шлюзом на пути дейтаграммы. Хост, принимающий источник, должен на некоторое время вернуться обратно, а затем постепенно снова увеличивать скорость передачи. Механизм ответа на Source Quench может быть на транспортном уровне (для ориентированных на соединение протоколов, таких как TCP) или на прикладном уровне (для протоколов, построенных поверх UDP).

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

3.2.2.4 Превышено время

Входящее сообщение о превышении времени ДОЛЖНО быть передано на транспортный уровень.

Обсуждение:

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

Хост может получить сообщение «Код превышения времени 1 (время ожидания повторной сборки)» от хоста назначения, для которого истекло время ожидания и отброшена неполная дейтаграмма; см. раздел 3.3.2 ниже. В будущем получение этого сообщения может быть частью некоторой процедуры «обнаружения MTU», чтобы определить максимальный размер дейтаграммы, который можно отправить по пути без фрагментации.

3.2.2.5 Проблема с параметрами

Хост ДОЛЖЕН генерировать сообщения о проблемах параметров. Входящее сообщение о проблеме параметров ДОЛЖНО быть передано на транспортный уровень, и оно МОЖЕТ быть сообщено пользователю.

Обсуждение:

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

Настоящим определяется новый вариант сообщения о проблеме параметров:

Код 1 = обязательная опция отсутствует.

Обсуждение:

Этот вариант в настоящее время используется в военном сообществе из-за отсутствующего параметра безопасности.

3.2.2.6 Эхо-запрос / ответ

Каждый хост ДОЛЖЕН реализовывать функцию эхо-сервера ICMP, которая получает эхо-запросы и отправляет соответствующие эхо-ответы. Хост ДОЛЖЕН также реализовать интерфейс прикладного уровня для отправки Эхо-запроса и получения Эхо-ответа, в целях диагностики.

Эхо-запрос ICMP, предназначенный для широковещательного IP-адреса или многоадресного IP-адреса, МОЖЕТ быть отброшен без уведомления.

Обсуждение:

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

Адрес источника IP в эхо-ответе ICMP ДОЛЖЕН совпадать с адресом конкретного назначения (определенным в разделе 3.2.1.3) соответствующего сообщения эхо-запроса ICMP.
Данные, полученные в эхо-запросе ICMP, ДОЛЖНЫ быть полностью включены в итоговый эхо-ответ. Однако, если отправка эхо-ответа требует преднамеренной фрагментации, которая не реализована, дейтаграмма ДОЛЖНА быть усечена до максимального размера передачи (см. Раздел 3.3.3) и отправлена.

Сообщения эхо-ответа ДОЛЖНЫ передаваться в пользовательский интерфейс ICMP, если только соответствующий эхо-запрос не возник на уровне IP.

Если в эхо-запросе ICMP получен параметр «Маршрут записи и / или отметка времени», этот параметр (эти параметры) СЛЕДУЕТ обновить, включив в него текущий хост и включив его в заголовок IP сообщения «Эхо-ответ», без «усечения». Таким образом, записанный маршрут будет для всего туда-обратно.

Если опция исходного маршрута получена в эхо-запросе ICMP, обратный маршрут ДОЛЖЕН быть обращен вспять и использоваться в качестве опции исходного маршрута для сообщения эхо-ответа.

 

3.2.2.7 Запрос информации / ответ

Хост не ДОЛЖЕН реализовывать эти сообщения.

Обсуждение:

Пара «Запрос информации / ответ» предназначалась для поддержки самонастраивающихся систем, таких как бездисковые рабочие станции, чтобы они могли обнаруживать свои номера IP-сетей во время загрузки. Однако протоколы RARP и BOOTP предоставляют более эффективные механизмы для хоста, чтобы обнаружить его собственный IP-адрес.

3.2.2.8 Отметка времени и ответ отметки времени

Хост МОЖЕТ реализовать Timestamp и Timestamp Reply. Если они реализованы, ДОЛЖНЫ соблюдаться следующие правила.

• Функция сервера ICMP Timestamp возвращает ответ Timestamp каждому полученному сообщению Timestamp. Если эта функция реализована, она ДОЛЖНА быть спроектирована для минимальной изменчивости задержки (например, реализована в ядре, чтобы избежать задержки в планировании пользовательского процесса).

Следующие случаи для Timestamp должны обрабатываться в соответствии с соответствующими правилами для ICMP Echo:

• Сообщение запроса временной метки ICMP к широковещательному IP-адресу или многоадресному IP-адресу МОЖЕТ быть отброшено без предупреждения.
• IP-адрес источника в ответе метки времени ICMP ДОЛЖЕН совпадать с адресом конкретного назначения соответствующего сообщения запроса метки времени.
• Если опция Source-route получена в эхо-запросе ICMP, обратный маршрут ДОЛЖЕН быть обращен вспять и использоваться в качестве опции Source Route для сообщения-ответа с отметкой времени.
• Если в запросе на временную метку получен параметр «Маршрут записи и / или временная метка», эту (-ые) опцию (-и) СЛЕДУЕТ обновить, чтобы включить текущий хост и включить в заголовок IP сообщения ответа на метку времени.
• Входящие сообщения с ответами на метки времени ДОЛЖНЫ передаваться в пользовательский интерфейс ICMP.

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

(a) «Стандартное значение» ДОЛЖНО обновляться, по меньшей мере, 15 раз в секунду (т.е. максимум шесть младших битов значения могут быть неопределенными).

(b) Точность «стандартного значения» ДОЛЖНА быть приближена к точности установленных на операторе тактовых импульсов ЦП, т. е. корректироваться в течение нескольких минут.

 

3.2.2.9 Адрес Маска Запрос / Ответ

Хост ДОЛЖЕН поддерживать первый и МОЖЕТ реализовывать все три следующих способа определения маски (ей) адреса, соответствующей его IP-адресу (ам):

1. статическая информация о конфигурации;
2. динамическое получение маски (ей) адреса в качестве побочного эффекта процесса инициализации системы (см. [INTRO: 1]); а также
3. отправка запроса (ей) маски адреса ICMP и получение ответа (ов) маски адреса ICMP.

Выбор метода для использования на конкретном хосте ДОЛЖЕН быть настраиваемым.

Когда метод (3), использование сообщений маски адреса, включен, то:

• (a) Когда он инициализируется, хост ДОЛЖЕН транслировать сообщение запроса маски адреса в подключенной сети, соответствующее IP-адресу. Он ДОЛЖЕН повторно передать это сообщение несколько раз, если не получит немедленный ответ по маске адреса.
• (b) Пока он не получит ответ маски адреса, хост ДОЛЖЕН принять маску, соответствующую классу адреса IP-адреса, то есть предположить, что подключенная сеть не имеет подсети.
• (c) Первое полученное сообщение с ответом маски адреса ДОЛЖНО использоваться для установки маски адреса, соответствующей конкретному локальному IP-адресу. Это верно даже в том случае, если первое сообщение с ответом на маску адреса является «незапрошенным», и в этом случае оно будет передано и может прибыть после того, как хост прекратит повторную передачу запросов маски адреса. После того, как маска была установлена ​​ответом маски адреса, последующие сообщения ответа маски адреса ДОЛЖНЫ (молча) игнорироваться.

И наоборот, если сообщения Address Mask отключены, то запросы ICMP Address Mask отправляться не будут, и любые ответы ICMP Address Mask, полученные для этого локального IP-адреса, ДОЛЖНЫ (молча) игнорироваться.

Хост ДОЛЖЕН проверить правильность любой установленной маски адреса; см. ниже раздел РЕАЛИЗАЦИЯ.

Система НЕ ДОЛЖНА отправлять ответ с адресной маской, если она не является уполномоченным агентом для адресных масок. Авторитетным агентом может быть хост или шлюз, но он ДОЛЖЕН быть явно настроен как агент маски адреса. Получение маски адреса с помощью ответа маски адреса не дает права получателя и НЕ ДОЛЖНО использоваться в качестве основы для выдачи ответов маски адреса.

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

Если он настроен как агент, хост ДОЛЖЕН транслировать ответ маски адреса для маски на соответствующем интерфейсе при инициализации.

См. «Инициализация системы» в [INTRO: 1] для получения дополнительной информации об использовании сообщений запроса / ответа маски адреса.

ОБСУЖДЕНИЕ

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

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

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

РЕАЛИЗАЦИЯ:

Предлагается следующая проверка правильности адресной маски: маска — это не все 1 бит, и она либо равна нулю, либо включены 8 старших битов.

3.2.3 Интернет-протокол управления группами IGMP

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

В настоящее время реализация IGMP НЕОБЯЗАТЕЛЬНА; см. раздел 3.3.7 для получения дополнительной информации. Без IGMP хост все равно может участвовать в многоадресной рассылке локально для своих подключенных сетей.

 

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

3.3.1 Маршрутизация исходящих дейтаграмм

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

3.3.1.1 Локальное / дистанционное решение

Чтобы решить, находится ли пункт назначения в подключенной сети, ДОЛЖЕН использоваться следующий алгоритм [см. IP: 3]:

• (a) Маска адреса (в частности, для локального IP-адреса для многосетевого хоста) представляет собой 32-битную маску, которая выбирает поля номера сети и номера подсети соответствующего IP-адреса.
• (b) Если биты IP-адреса назначения, извлеченные с помощью маски адреса, совпадают с битами IP-адреса источника, извлеченными с помощью той же маски, тогда адресат находится в соответствующей подключенной сети, и дейтаграмма должна быть передана непосредственно на хост-приемник.
• (c) Если нет, то пункт назначения доступен только через шлюз. Выбор шлюза описан ниже (3.3.1.2).

Адрес получателя в особом случае обрабатывается следующим образом:

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

Уровень IP хоста ДОЛЖЕН работать корректно в минимальной сетевой среде, в частности, когда нет шлюзов. Например, если уровень IP хоста настаивает на поиске по крайней мере одного шлюза для инициализации, хост не сможет работать в одной изолированной широковещательной сети.

3.3.1.2 Выбор шлюза

Чтобы эффективно направить серию дейтаграмм в один и тот же пункт назначения, хост-источник ДОЛЖЕН хранить «кэш маршрутов» сопоставлений со шлюзами следующего перехода. Хост использует следующий основной алгоритм в этом кэше для маршрутизации дейтаграммы; Этот алгоритм предназначен для того, чтобы обременять основные шлюзы [IP: 11].

• (a) Если кэш маршрутов не содержит информации для конкретного пункта назначения, хост выбирает шлюз «по умолчанию» и отправляет ему дейтаграмму. Он также создает соответствующую запись в Route Cache.
• (b) Если этот шлюз не является наилучшим следующим переходом к месту назначения, шлюз направит дейтаграмму к лучшему шлюзу следующего перехода и вернет сообщение перенаправления ICMP на хост-источник.
• (c) Когда он получает Redirect, хост обновляет шлюз следующего перехода в соответствующей записи кэша маршрутов, поэтому более поздние дейтаграммы к тому же месту назначения будут идти непосредственно к лучшему шлюзу.

Поскольку маска подсети, соответствующая адресу назначения, как правило, неизвестна, сообщение о перенаправлении сети ДОЛЖНО обрабатываться идентично сообщению перенаправления хоста; то есть запись кэша для хоста назначения (только) будет обновлена (или создана, если запись для этого хоста не существует) для нового шлюза.

Обсуждение:

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

Если для адреса хоста назначения нет записи в кэше маршрутов (и адресат не находится в подключенной сети), уровень IP ДОЛЖЕН выбрать шлюз из своего списка «шлюзов по умолчанию». Уровень IP ДОЛЖЕН поддерживать несколько шлюзов по умолчанию.

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

Обсуждение:

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

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

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

3.3.1.3 Кэш-память маршрута

Каждая запись кэша маршрутов должна включать следующие поля:

1. Локальный IP-адрес (для многосетевого хоста)
2. IP-адрес назначения
3. Тип (ы) обслуживания
4. IP-адрес шлюза следующего перехода

Поле (2) МОЖЕТ быть полным IP-адресом хоста назначения или только номером сети назначения. Поле (3), ТОС, ДОЛЖНО быть включено.

См. Раздел 3.3.4.2 для обсуждения значения множественной адресации для процедуры поиска в этом кэше.

Обсуждение:

Включение поля Type-of-Service в кэш маршрутов и рассмотрение его в алгоритме маршрутизации хоста обеспечит необходимый механизм для будущего, когда маршрутизация Type-of-Service обычно используется в Интернете. См. Раздел 3.2.1.6.

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

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

1. Как требуется в Разделе 3.3.1.2, сообщения о перенаправлении обычно приводят к записям, привязанным к адресам хоста назначения; самая простая и самая общая схема состояла бы в том, чтобы всегда использовать адреса хоста.
2. Уровень IP не всегда может знать маску адреса для сетевого адреса в сложной подсетевой среде.
3. Использование только адресов хостов позволяет использовать адрес назначения в качестве чистого 32-битного числа, что может позволить в будущем расширять архитектуру Интернета без каких-либо изменений для хостов.

Противоположное мнение заключается в том, что в кеше маршрута можно смешивать целевые хосты и сети:

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

РЕАЛИЗАЦИЯ:

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

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

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

 

3.3.1.4 Обнаружение мертвого шлюза

Уровень IP ДОЛЖЕН быть в состоянии обнаружить сбой шлюза «nexthop», который указан в его кэше маршрутов, и выбрать альтернативный шлюз (см. Раздел 3.3.1.5).

Обнаружение мертвого шлюза подробно описано в RFC-816 [IP: 11]. Опыт на сегодняшний день не дал полного алгоритма, который был бы полностью удовлетворительным, хотя он определил несколько запрещенных путей и многообещающих методов.

• Определенный шлюз НЕ ДОЛЖЕН использоваться бесконечно в отсутствие положительных признаков того, что он функционирует.
• Активные пробники, такие как «пинг» (т. Е. С использованием обмена эхо-запросами и ответами ICMP), дороги и плохо масштабируются. В частности, хосты НЕ ДОЛЖНЫ активно проверять состояние шлюза первого перехода, просто непрерывно проверяя его.
• Даже если это единственный эффективный способ проверки состояния шлюза, пинг ДОЛЖЕН использоваться только тогда, когда трафик отправляется на шлюз и когда нет других положительных признаков, свидетельствующих о том, что шлюз функционирует.
• Чтобы избежать проверки связи, уровни выше и / или ниже уровня Интернета ДОЛЖНЫ иметь возможность давать «советы» о состоянии записей кэша маршрутов, когда доступна либо положительная (шлюз в норме), либо отрицательная (шлюз не работает).

Обсуждение:

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

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

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

• TCP или любой транспортный протокол с установлением соединения должен быть в состоянии дать отрицательный совет, например, вызванный чрезмерной повторной передачей.
• TCP может дать положительный совет, когда (новые) данные будут подтверждены. Даже если маршрут может быть асимметричным, ACK для новых данных доказывает, что подтвержденные данные должны были быть успешно переданы.
• Сообщение ICMP Redirect от определенного шлюза должно использоваться в качестве положительного совета об этом шлюзе.
• Информация о канальном уровне, которая надежно обнаруживает и сообщает о сбоях хоста (например, сообщения ARPANET Destination Dead), должна использоваться как негативный совет.
• Отказ ARP или повторная проверка сопоставлений ARP могут использоваться в качестве отрицательного совета для соответствующего IP-адреса.
• Пакеты, поступающие с определенного адреса канального уровня, являются свидетельством того, что система по этому адресу жива. Однако для превращения этой информации в рекомендации о шлюзах требуется сопоставить адрес канального уровня с IP-адресом, а затем проверить этот IP-адрес в сравнении со шлюзами, указанными в кэше маршрутов. Это, вероятно, чрезмерно неэффективно.

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

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

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

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

В настоящее время пинг (то есть с использованием эхо-сообщений ICMP) является механизмом проверки шлюза, когда это абсолютно необходимо. Успешный пинг гарантирует, что адресуемый интерфейс и связанная с ним машина работают, но не гарантирует, что машина является шлюзом, а не хостом. Обычный вывод состоит в том, что если Redirect или другое свидетельство указывает, что машина была шлюзом, успешные эхо-запросы будут указывать, что машина все еще работает и, следовательно, все еще шлюз. Однако, поскольку хост молча отбрасывает пакеты, которые шлюз будет перенаправлять или перенаправлять, такое допущение иногда может потерпеть неудачу. Чтобы избежать этой проблемы, новое разрабатываемое сообщение ICMP спросит: «Вы шлюз?»

РЕАЛИЗАЦИЯ:

Был предложен следующий конкретный алгоритм:

• Свяжите «таймер перенаправления» с каждым шлюзом, на который указывает кэш маршрутов. Инициализируйте таймер значением Tr, которое должно быть достаточно маленьким, чтобы позволить обнаружение мертвого шлюза до истечения времени ожидания транспортных соединений.
• Положительный совет сбросил бы таймер перенаправления на Tr. Отрицательный совет уменьшит или обнулит таймер перенаправления.
• Всякий раз, когда уровень IP использует определенный шлюз для маршрутизации дейтаграммы, он проверяет соответствующий таймер перенаправления. Если время таймера истекло (достигло нуля), уровень IP отправил бы пинг к шлюзу, после чего немедленно была бы датаграмма.
• Пинг (ICMP Echo) будет отправлен снова, если необходимо, до N раз. Если в N попыток не было получено ни одного ping-ответа, предполагалось, что шлюз отказал, и для всех записей кэша, указывающих на отказавший шлюз, будет выбран новый шлюз первого перехода.

Обратите внимание, что размер Tr обратно пропорционален количеству доступных советов. Тр должен быть достаточно большим, чтобы обеспечить:

• Любой пинг будет на низком уровне (например, <10%) всех пакетов, отправляемых на шлюз с хоста,
• пинг редко (например, каждые 3 минуты)

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

3.3.1.5 Выбор нового шлюза

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

Обсуждение:

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

РЕАЛИЗАЦИЯ:

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

3.3.1.6 Инициализация

Следующая информация ДОЛЖНА быть настраиваемой:

(1) IP-адрес (а).
(2) Адресная маска (и).
(3) Список шлюзов по умолчанию с предпочтительным уровнем.

НЕОБХОДИМО предоставить ручной метод ввода этих данных конфигурации. Кроме того, различные методы могут быть использованы для динамического определения этой информации; см. раздел «Инициализация хоста» в [INTRO: 1].

Обсуждение:

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

3.3.2 Сборка

Уровень IP ДОЛЖЕН осуществлять повторную сборку дейтаграмм IP.

Мы определяем самый большой размер дейтаграммы, который может быть повторно собран EMTU_R («Эффективный MTU для приема»); это иногда называют «размером буфера сборки». EMTU_R ДОЛЖЕН быть больше или равен 576, ДОЛЖЕН быть либо конфигурируемым, либо неопределенным, и ДОЛЖЕН быть больше или равен MTU подключенной сети (сетей).

Обсуждение:

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

РЕАЛИЗАЦИЯ:

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

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

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

поскольку 20 — это минимальный размер заголовка IP.

Должен быть тайм-аут для повторной сборки. Значение таймаута повторной сборки ДОЛЖНО быть фиксированным значением, не заданным из оставшихся TTL. Рекомендуется, чтобы значение находилось в диапазоне от 60 секунд до 120 секунд. Если этот тайм-аут истекает, частично собранные датаграммы ДОЛЖНЫ быть отброшены, и сообщение ICMP Time Exceeded отправлено на хост-источник (если был получен нулевой фрагмент).

Обсуждение:

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

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

Если время повторной сборки слишком велико, ресурсы буфера на принимающем хосте будут связаны слишком долго, и MSL (максимальное время жизни сегмента) [TCP: 1] будет больше, чем необходимо. MSL контролирует максимальную скорость, с которой фрагментированные дейтаграммы могут отправляться с использованием различных значений 16-битного поля Ident; большее значение MSL снижает максимальную скорость. Спецификация TCP [TCP: 1] произвольно принимает значение 2 минуты для MSL. Это устанавливает верхний предел разумного значения времени ожидания сборки.

 

3.3.3 Фрагментация

Необязательно, уровень IP МОЖЕТ реализовать механизм преднамеренного фрагментирования исходящих дейтаграмм.

Мы определяем EMTU_S («Эффективный MTU для отправки») максимальный размер дейтаграммы IP, который может быть отправлен, для конкретной комбинации адресов источника и назначения IP и, возможно, TOS.

Хост ДОЛЖЕН реализовывать механизм, позволяющий транспортному уровню изучать MMS_S, максимальный размер сообщения транспортного уровня, который может быть отправлен для данного триплета {источник, пункт назначения, TOS} (см. Вызов GET_MAXSIZES в разделе 3.4). Если локальная фрагментация не выполняется, значение MMS_S будет:

MMS_S = EMTU_S — <IP header size>

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

 

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

Было предложено, чтобы хост мог определить MTU по заданному пути, отправив фрагмент дейтаграммы с нулевым смещением и ожидая, пока получатель не истечет время повторной сборки (что не может быть завершено!) И вернет сообщение ICMP Time Exceeded. Это сообщение будет включать в себя самый большой оставшийся заголовок фрагмента в своем теле. С более прямыми механизмами экспериментируют, но они еще не приняты (см., Например, RFC-1063).

 

3.3.4 Локальное множественное возвращение

3.3.4.1 Введение

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

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

(а) Несколько логических сетей

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

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

(б) Несколько логических хостов

Когда у хоста есть несколько IP-адресов, которые имеют одинаковую часть <Network-number> (и одну и ту же часть <Subnetnumber>, если есть), логические интерфейсы называются «логическими узлами». Эти логические интерфейсы могут совместно использовать один физический интерфейс или могут использовать отдельные физические интерфейсы для одной и той же физической сети.

(c) Простое множественное возвращение

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

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

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

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

В архитектуре Интернет-протокола экземпляр транспортного протокола («объект») не имеет собственного адреса, а вместо этого использует один адрес Интернет-протокола (IP). Это имеет значение для уровней IP, транспорта и приложений, а также для интерфейсов между ними. В частности, прикладному программному обеспечению может потребоваться информация о множественных IP-адресах многосетевого хоста; в других случаях выбор может быть сделан внутри сетевого программного обеспечения.

3.3.4.2 Требования к множественной адресации

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

(1) Если дейтаграмма отправляется в ответ на полученную дейтаграмму, адрес источника для ответа ДОЛЖЕН быть адресом конкретного назначения запроса. См. Разделы 4.1.3.5 и 4.2.3.7 и раздел «Общие вопросы» [INTRO: 1] для более конкретных требований к более высоким уровням.

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

(2) Приложение ДОЛЖНО иметь возможность явно указывать адрес источника для инициирования соединения или запроса.

(3) В отсутствие такой спецификации сетевое программное обеспечение ДОЛЖНО выбирать адрес источника. Правила для этого выбора описаны ниже.

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

• (A) Хост МОЖЕТ молча отбросить входящую дейтаграмму, адрес назначения которой не соответствует физическому интерфейсу, через который она получена.
• (B) Хост МОЖЕТ ограничить себя отправкой (не исходящих) IP-дейтаграмм только через физический интерфейс, который соответствует IP-адресу источника дейтаграмм.

Обсуждение:

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

o Сильная модель ES

Модель Strong ES (End System, то есть хост) подчеркивает различие хост / шлюз (ES / IS) и, следовательно, заменяет MUST на MAY в вопросах (A) и (B) выше. Он имеет тенденцию моделировать многосетевой хост как набор логических хостов в пределах одного физического хоста.

Что касается (A), сторонники модели Strong ES отмечают, что механизмы автоматической интернет-маршрутизации не могли направить дейтаграмму к физическому интерфейсу, который не соответствовал адресу назначения.

В модели Strong ES вычисление маршрута для исходящей дейтаграммы является отображением:

route(src IP addr, dest IP addr, TOS) -> gateway

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

o Слабая модель ES

Эта точка зрения лишает акцента различия между ES / IS и поэтому НЕ ДОЛЖНА заменять MAY в вопросах (A) и (B). Эта модель может быть более естественной для хостов, использующих протоколы маршрутизации шлюза для прослушивания, и необходима для хостов, которые имеют встроенные функции шлюза.

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

В слабой модели ES вычисление маршрута для исходящей дейтаграммы является отображением:

route(dest IP addr, TOS) -> gateway, interface

3.3.4.3 Выбор адреса источника

Обсуждение:

Когда он отправляет начальный запрос соединения (например, сегмент TCP «SYN») или запрос службы дейтаграммы (например, запрос на основе UDP), транспортный уровень на многосетевом хосте должен знать, какой адрес источника использовать. Если приложение не указывает его, транспортный уровень должен попросить уровень IP выполнить концептуальное отображение:

GET_SRCADDR(remote IP addr, TOS) -> local IP address

Здесь TOS — это значение типа обслуживания (см. Раздел 3.2.1.6), а результатом является желаемый адрес источника. Для реализации этого сопоставления предлагаются следующие правила:

• (a) Если адрес удаленного Интернета находится в одной из (под) сетей, к которым хост напрямую подключен, может быть выбран соответствующий адрес источника, если не известно, что соответствующий интерфейс не работает.
• (b) можно обратиться к кэшу маршрутов, чтобы узнать, существует ли активный маршрут к указанной сети назначения через какой-либо сетевой интерфейс; если это так, может быть выбран локальный IP-адрес, соответствующий этому интерфейсу.
• (c) Таблица статических маршрутов, если таковые имеются (см. раздел 3.3.1.2), может быть использована аналогичным образом.
• (d) С шлюзами по умолчанию можно ознакомиться. Если эти шлюзы назначены различным интерфейсам, может быть выбран интерфейс, соответствующий шлюзу с наивысшим предпочтением.

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

РЕАЛИЗАЦИЯ:

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

3.3.5 Пересылка исходного маршрута

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

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

(A) TTL (см. Раздел 3.2.1.7)

Поле TTL ДОЛЖНО быть уменьшено, а датаграмма, возможно, отброшена, как указано для шлюза в [INTRO: 2].

(B) пункт назначения ICMP недоступен (см. Раздел 3.2.2.1)

Хост ДОЛЖЕН иметь возможность генерировать сообщения о недостижимости пункта назначения со следующими кодами:

• 4 (Фрагментация обязательна, но установлен DF), когда дейтаграмма с исходным потоком не может быть фрагментирована для соответствия целевой сети;
• 5 (Исходный маршрут не выполнен), когда датаграмма с исходной маршрутизацией не может быть перенаправлена, например, из-за проблемы маршрутизации или из-за того, что следующий переход строгого исходного маршрута отсутствует в подключенной сети.

(C) IP-адрес источника (см. Раздел 3.2.1.3)

Пересылаемая исходная датаграмма МОЖЕТ (и обычно будет) иметь исходный адрес, который не является одним из IP-адресов пересылающего хоста.

(D) Опция записи маршрута (см. Раздел 3.2.1.8d)

Хост, который пересылает дейтаграмму с маршрутизацией от источника, содержащую опцию Record Route, ДОЛЖЕН обновить эту опцию, если у нее есть место.

(E) Опция отметки времени (см. Раздел 3.2.1.8e)

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

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

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

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

 

3.3.6 Трансляции

В разделе 3.2.1.3 определены четыре стандартные формы широковещательных IP-адресов:

Ограниченная трансляция (Limited Broadcast): {-1, -1}

Направленная трансляция (Directed Broadcast): {<номер сети>, — 1}

Трансляция, направленная на подсеть (Subnet Directed Broadcast): {<Сетевой номер>, <номер подсети>, — 1}

Трансляция, направленная на все подсети (All-Subnets Directed Broadcast): {<номер сети>, — 1, -1}

Хост ДОЛЖЕН распознавать любую из этих форм по адресу назначения входящей дейтаграммы.

Существует класс хостов (Unix * 4.2BSD и его производные, но не 4.3BSD.), которые используют нестандартные формы широковещательного адреса, заменяя 0 на -1. Все хосты ДОЛЖНЫ  распознавать и принимать любой из этих нестандартных широковещательных адресов в качестве адреса назначения входящей дейтаграммы. Хост МОЖЕТ при желании иметь опцию конфигурации для выбора формы широковещательного адреса 0 или -1 для каждого физического интерфейса, но эта опция ДОЛЖНА по умолчанию использовать стандартную (-1) форму.

Когда хост отправляет дейтаграмму на широковещательный адрес канального уровня, IP-адрес назначения ДОЛЖЕН быть допустимым широковещательным IP-адресом или многоадресным IP-адресом.

Хост ДОЛЖЕН молча отбрасывать дейтаграмму, полученную через широковещательную рассылку канального уровня (см. Раздел 2.4), но не указывать IP-адрес многоадресной рассылки или широковещательный адрес назначения.

Хостам СЛЕДУЕТ использовать адрес ограниченной широковещательной рассылки для широковещательной передачи в подключенную сеть.

Обсуждение:

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

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

 

3.3.7 Многоадресная рассылка IP

Хост ДОЛЖЕН поддерживать локальную многоадресную IP-рассылку во всех подключенных сетях, для которых было задано сопоставление IP-адресов класса D и адресов канального уровня (см. Ниже). Поддержка локальной многоадресной IP-рассылки включает отправку многоадресных дейтаграмм, присоединение к группам многоадресной рассылки и получение многоадресных дейтаграмм, а также выход из групп многоадресной рассылки. Это подразумевает поддержку всех [IP: 4], кроме самого протокола IGMP, который является ФАКУЛЬТАТИВНЫМ.

Обсуждение:

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

Если IGMP не реализован, хост ДОЛЖЕН присоединиться к группе «allhosts» (224.0.0.1), когда уровень IP инициализируется и остается участником до тех пор, пока уровень IP активен.

Обсуждение:

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

Отображение адресов IP класса D на локальные адреса в настоящее время определено для следующих типов сетей:
o Ethernet / IEEE 802.3, как определено в [IP: 4].

o Любая сеть, которая поддерживает широковещательную, но не многоадресную адресацию, все адреса IP класса D отображаются на локальный широковещательный адрес.

o Любой тип двухточечной связи (например, ссылки SLIP или HDLC): сопоставление не требуется. Все IP-дейтаграммы многоадресной рассылки отправляются как есть, внутри локального фрейма.

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

Хост ДОЛЖЕН предоставлять протоколам или приложениям более высокого уровня способ определить, какие из подключенных к хосту сетей поддерживают IP-адресацию.

3.3.8 Сообщение об ошибке

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

Обсуждение:

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

 

3.4 Интерфейс интернет / транспортного уровня

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

Обсуждение:

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

Теперь мы опишем концептуальный интерфейс между транспортным уровнем и уровнем IP как набор вызовов процедур. Это расширение информации в разделе 3.3 RFC-791 [IP: 1].

• * Отправить датаграмму
• * Получить датаграмму
• * Выберите адрес источника
• * Найти максимальные размеры датаграмм
• * Советы по успешной доставке
• * Отправить сообщение ICMP
• * Получить сообщение ICMP

Отправить датаграмму — Send Datagram

SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result )

где параметры определены в RFC-791. Передавать параметр Id необязательно; см. раздел 3.2.1.5.

Получить датаграмму — Receive Datagram

RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt)

Все параметры определены в RFC-791, кроме:

SpecDest = specific-destination address of datagram (defined in Section 3.2.1.3)

Параметр результата dst содержит адрес назначения дейтаграммы. Поскольку это может быть широковещательный или многоадресный адрес, параметр SpecDest (не показан в RFC-791) ДОЛЖЕН быть передан. Параметр opt содержит все параметры IP, полученные в дейтаграмме; они также ДОЛЖНЫ передаваться на транспортный уровень.

Выберите адрес источника — Select Source Address

GET_SRCADDR(remote, TOS) -> local
remote = remote IP address
TOS = Type-of-Service
local = local IP address

Смотри Раздел 3.3.4.3

Найти максимальные размеры датаграмм — Find Maximum Datagram Sizes

GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
MMS_R = maximum receive transport-message size.
MMS_S = maximum send transport-message size.
(local, remote, TOS defined above)

Смотри Раздел 3.3.2. и 3.3.3.

Советы по успешной доставке — Advice on Delivery Success

ADVISE_DELIVPROB(sense, local, remote, TOS)

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

Отправить сообщение ICMP — Send ICMP Message

SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt)
-> result

(Parameters defined in RFC-791)

Передавать параметр Id необязательно; см. раздел 3.2.1.5. Транспортный уровень ДОЛЖЕН иметь возможность отправлять определенные сообщения ICMP: «Порт недоступен» или любые сообщения типа запроса. Конечно, эту функцию можно считать частным случаем вызова SEND (); мы опишем это отдельно для ясности.

Получить сообщение ICMP — Receive ICMP Message

RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
(Parameters defined in RFC-791).

Уровень IP ДОЛЖЕН передавать определенные сообщения ICMP до соответствующей процедуры транспортного уровня. Разумеется, эту функцию можно считать частным случаем вызова RECV (); мы опишем это отдельно для ясности.

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

В частности, должны быть переданы следующие сообщения ICMP:

• Пункт назначения недоступен
• Источник гасит
• Эхо-ответ (для пользовательского интерфейса ICMP, если только эхо-запрос не возник на уровне IP)
• Ответ отметки времени (для пользовательского интерфейса ICMP)
• Превышено время

Обсуждение:

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

3.5 Сводка требований интернет-уровня

Внедрить IP и ICMP (MUST — обязан)

Обработка удаленного множественного поиска на уровне приложений (MUST — обязан)

Поддержка локального мультихоминга (MAY — возможна)

Удовлетворить спецификации шлюза при пересылке дейтаграмм (MUST — обязан)

Конфигурационный переключатель для встроенного шлюза (MUST — обязан) (Footnotte = 1)

Конфигурационный переключатель по умолчанию для не шлюза (MUST — обязан) (Footnotte = 1)

Автоконфигурация на основе количества интерфейсов (MUST NOT — не обязан) (Footnotte = 1)

Возможность записи сброшенных дейтаграмм (SHOULD — должен)

Запись в счетчик (SHOULD — должен)

 

Молча сбросить версию! = 4 (MUST — обязан)
Проверьте контрольную сумму IP, молча отбросьте плохой дграм (MUST — обязан)
Решение:
Адресация подсети (RFC-950) (MUST — обязан)
Адрес Src должен быть собственным IP-адресом хоста. (MUST — обязан)
Молча отбросить дейтаграмму с плохим адресом назначения (MUST — обязан)
Молча отбросить дейтаграмму с плохим адресом src (MUST — обязан)
Поддержка сборки (MUST — обязан)
Сохранить то же поле Id в идентичной датаграмме (MAY — возможна)

TOS:
Разрешить транспортному слою установить TOS (MUST — обязан)
Передача полученных TOS до транспортного уровня (SHOULD — должен)
Используйте сопоставления канального уровня RFC-795 для TOS (SHOULD NOT — не должен)
TTL:
Отправить пакет с TTL 0 (MUST NOT — не обязан)
Сбросить полученные пакеты с TTL <2 (MUST NOT — не обязан)
Разрешить транспортному уровню устанавливать TTL (MUST — обязан)
Фиксированный TTL настраивается (MUST — обязан)

Опции IP:
Разрешить транспортному уровню отправлять параметры IP (MUST — обязан)
Передать все параметры IP rcvd на верхний уровень (MUST — обязан)
IP-уровень молча игнорирует неизвестные параметры (MUST — обязан)
Опция безопасности (MAY — возможна)
Опция отправки идентификатора потока (SHOULD NOT — не должен)
Молча игнорировать опцию идентификатора потока (MUST — обязан)
Опция записи маршрута (MAY — возможна)
Опция отметки времени (MAY — возможна)

Вариант исходного маршрута:
Инициировать и прекратить опции исходного маршрута (MUST — обязан)
Датаграмма с завершенным SR передана в TL (MUST — обязан)
Построить правильный (не избыточный) обратный маршрут (MUST — обязан)
Отправить несколько параметров SR в одном заголовке (MUST NOT — не обязан)

ICMP:
Молча отменить ICMP MSG с неизвестным типом (MUST — обязан)
Включите более 8 октетов датаграммы происхождения (MAY — возможна)
Включенные октеты такие же как полученные (MUST — обязан)
Demux ICMP Ошибка в транспортном протоколе (MUST — обязан)
Отправить сообщение об ошибке ICMP с TOS = 0 (SHOULD — должен)
Отправить сообщение об ошибке ICMP для:
— Ошибка ICMP (MUST NOT — не обязан)
— IP b’cast или IP m’cast (MUST NOT — не обязан)
— Канал канального уровня (MUST NOT — не обязан)
— не начальный фрагмент (MUST NOT — не обязан)
— датаграмма с неуникальным адресом src (MUST NOT — не обязан)
Возвращать сообщения об ошибках ICMP (если не запрещено)  (MUST — обязан)

Dest недоступен:
Создать Dest недоступен (код 2/3) (SHOULD — должен)
Передача ICMP Dest недоступна для более высокого уровня (MUST — обязан)
Высший слой действует на Dest Unreach (SHOULD — должен)
Интерпретируйте Dest Unreach как только подсказку (MUST — обязан)
Перенаправление:
Host send Redirect (SHOULD NOT — не должен)
Обновление кеша маршрута при recv Redirect (MUST — обязан)
Обрабатывать перенаправления как хоста, так и сети (MUST — обязан)
Отменить незаконное перенаправление (SHOULD — должен)
Источник гасит:
Отправить Source Quench, если буфер превышен (MAY — возможна)
Пропустите Source Quench для более высокого уровня (MUST — обязан)
Высший слой действует на источник гашения (SHOULD — должен)
Превышено время: переход на более высокий уровень (MUST — обязан)
Параметр Проблема:
Отправить сообщение о проблеме (SHOULD — должен)
Передать проблему параметров в верхний уровень (MUST — обязан)
Сообщить о проблеме с параметром пользователю (MAY — возможна)

ICMP эхо-запрос или ответ:
Эхо-сервер и Эхо-клиент (MUST — обязан)
Эхо-клиент (SHOULD — должен)
Discard Echo Запрос на широковещательный адрес (MAY — возможна)
Discard Echo Запрос на многоадресный адрес (MAY — возможна)
Использовать конкретный адрес в качестве эхо-ответа src (MUST — обязан)
Отправить те же данные в Echo Ответить (MUST — обязан)
Передайте Echo Reply на верхний уровень (MUST — обязан)
Отражение маршрута записи, опции отметки времени (SHOULD — должен)
Инвертировать и отразить опцию Source Route (MUST — обязан)

Запрос информации ICMP или ответ: (SHOULD NOT — не должен)
ICMP Timestamp и Timestamp Ответ: (MAY — возможна)
Минимизировать изменчивость задержки (SHOULD — должен) (Footnotte = 1)
Тихо откажитесь от временной метки b’cast (MAY — возможна) (Footnotte = 1)
Тихо откажитесь от m’cast Timestamp (MAY — возможна) (Footnotte = 1)
Использовать конкретный адрес в качестве TS Ответить src (MUST — обязан) (Footnotte = 1)
Отражение маршрута записи, опции отметки времени (SHOULD — должен) (Footnotte = 1)
Инвертировать и отразить опцию Source Route (MUST — обязан) (Footnotte = 1)
Передача отметки времени Ответ на верхний уровень (MUST — обязан) (Footnotte = 1)
Соблюдайте правила для «стандартного значения» (MUST — обязан) (Footnotte = 1)

Запрос и ответ маски адреса ICMP:
Маска источника Addr настраивается (MUST — обязан)
Поддержка статической конфигурации маски addr (MUST — обязан)
Получить маску адреса динамически во время загрузки (MAY — возможна)
Получить адрес через ICMP Addr Mask Запрос / Ответ (MAY — возможна)
Повторно передать Addr Mask Req, если нет ответа (MUST — обязан) (Footnotte = 3)
Принять маску по умолчанию, если нет ответа (SHOULD — должен) (Footnotte = 3)
Обновить маску адреса только с первого ответа (MUST — обязан) (Footnotte = 3)
Проверка разумности по Адр Маска (SHOULD — должен)
Отправить неавторизованный Addr Mask Ответить msgs (MUST NOT — не обязан)
Явно настроен, чтобы быть агентом (MUST — обязан)
Статическая конфигурация => Addr-Mask-Authoritative flag (SHOULD — должен)
Broadcast Addr Mask Ответить при инициализации. (MUST — обязан) (Footnotte = 3)

МАРШРУТИЗАЦИЯ ИСХОДЯЩИХ ДАТАГРАММ:
Использовать маску адреса в локальном / удаленном решении (MUST — обязан)
Работать без шлюзов в сети (MUST — обязан)
Поддерживать «кэш маршрутов» шлюзов следующего перехода (MUST — обязан)
Относитесь к Host и Net Redirect одинаково (SHOULD — должен)
Если нет записи в кеш, используйте шлюз по умолчанию (MUST — обязан)
Поддержка нескольких шлюзов по умолчанию (MUST — обязан)
Предоставить таблицу статических маршрутов (MAY — возможна)
Флаг: маршрут, переопределяемый перенаправлениями (MAY — возможна)
Кеш маршрутов ключей на хосте, а не сетевой адрес (MAY — возможна)
Включить TOS в кеш маршрутов (SHOULD — должен)

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

СБОРКА И ФРАГМЕНТАЦИЯ:
Возможность собрать входящие дейтаграммы (MUST — обязан)
Не менее 576 байт дейтаграмм (MUST — обязан)
EMTU_R настраиваемый или неопределенный (SHOULD — должен)
Транспортный уровень способен выучить MMS_R (MUST — обязан)
Превышено время отправки ICMP по истечении времени ожидания сборки (MUST — обязан)
Исправлено значение таймаута повторной сборки (SHOULD — должен)

Передать MMS_S на верхние уровни (MUST — обязан)
Локальная фрагментация исходящих пакетов (MAY — возможна)
В противном случае не отправляйте больше, чем MMS_S (MUST — обязан)
Отправьте не более 576 пунктов назначения вне сети (SHOULD — должен)
Флаг конфигурации All-Subnets-MTU (MAY — возможна)

Многодомность:
Ответ с тем же адресом, что и у spec-dest addr (SHOULD — должен)
Разрешить приложению выбирать локальный IP-адрес (MUST — обязан)
Молча откажитесь от д’граммы в «неправильном» интерфейсе (MAY — возможна)
Отправляйте d’gram только через «правильный» интерфейс (MAY — возможна) (Footnotte = 4)

ИСТОЧНИК-МАРШРУТНАЯ ЭКСПЕДИЦИЯ:
Передача дейтаграммы с опцией Source Route (MAY — возможна) (Footnotte = 1)
Соблюдайте соответствующие правила шлюза (MUST — обязан) (Footnotte = 1)
Обновить TTL по правилам шлюза (MUST — обязан) (Footnotte = 1)
Возможность генерировать код ошибки ICMP 4, 5 (MUST — обязан) (Footnotte = 1)
IP src addr не локальный хост (MAY — возможна) (Footnotte = 1)
Обновить метку времени, параметры записи маршрута (MUST — обязан) (Footnotte = 1)
Конфигурируемый переключатель для нелокальной SRing (MUST — обязан) (Footnotte = 1)
По умолчанию выключено (MUST — обязан) (Footnotte = 1)
Удовлетворительные правила доступа для нелокальных SRing (MUST — обязан) (Footnotte = 1)
Если не вперед, отправьте Dest Unreach (CD 5) (SHOULD — должен) (Footnotte = 2)

Трансляция:
Трансляция адреса в качестве источника IP-адреса (SHOULD NOT — не должен)
Получите 0 или -1 формат вещания ОК (SHOULD — должен)
Конфигурируемая опция для отправки 0 или -1 b’cast (MAY — возможна)
По умолчанию -1 трансляция (SHOULD — должен)
Распознать все форматы широковещательных адресов (MUST — обязан)
Используйте IP-адрес b’cast / m’cast в канальном уровне b’cast (MUST — обязан)
Безмолвно отбрасывать только b’cast dg’s на канальном уровне (SHOULD — должен)
Используйте Limited Broadcast addr для подключенной сети (SHOULD — должен)

MULTICAST:
Поддержка локальной IP-адресации (RFC-1112) (SHOULD — должен)
Поддержка IGMP (RFC-1112) (MAY — возможна)
Присоединиться к группе all-hosts при запуске (SHOULD — должен)
Более высокие уровни учатся, я имею возможность вещания (SHOULD — должен)

ИНТЕРФЕЙС:
Разрешить транспортному уровню использовать все механизмы IP (MUST — обязан)
Передача идентификатора интерфейса на транспортный уровень (MUST — обязан)
Передать все параметры IP до транспортного уровня (MUST — обязан)
Транспортный уровень может отправлять определенные сообщения ICMP (MUST — обязан)
Передайте специальные ICMP-сообщения до транспорта. слой (MUST — обязан)
Включить IP HDR + 8 октетов или более из ориг. (MUST — обязан)
Способен прыгать высокие здания на одной границе (SHOULD — должен)

Примечания:
(1) Только если функция реализована.
(2) Это требование отменяется, если датаграмма является сообщением об ошибке ICMP.
(3) Только если функция реализована и настроена «на».
(4) Если у него нет встроенных функций шлюза или источник маршрутизируется.

4. Транспортные протоколы

4.1 Протокол дейтаграмм пользователя — UDP

4.1.1 Введение

Протокол пользовательских дейтаграмм UDP [UDP: 1] предлагает только минимальную транспортную услугу — негарантированную доставку дейтаграмм — и предоставляет приложениям прямой доступ к услуге дейтаграмм уровня IP. UDP используется приложениями, которым не требуется уровень обслуживания TCP или которые хотят использовать службы связи (например, многоадресная или широковещательная доставка), недоступные из TCP.

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

4.1.2 Прохождение протокола

В спецификации UDP нет известных ошибок.

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

4.1.3.1 Порты

Известные порты UDP следуют тем же правилам, что и известные порты TCP; см. раздел 4.2.2.1 ниже.

Если дейтаграмма поступает в адрес порта UDP, для которого нет ожидающего вызова LISTEN, UDP ДОЛЖЕН отправить сообщение о недоступности порта ICMP.

4.1.3.2 Параметры IP

UDP ДОЛЖЕН прозрачно передавать любую опцию IP, которую он получает от уровня IP, на прикладной уровень.

Приложение ДОЛЖНО иметь возможность указывать параметры IP для отправки в своих дейтаграммах UDP, а UDP ДОЛЖЕН передавать эти параметры на уровень IP.

Обсуждение:

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

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

4.1.3.3 ICMP-сообщения

UDP ДОЛЖЕН передавать на прикладной уровень все сообщения об ошибках ICMP, которые он получает от IP-уровня. Концептуально, по крайней мере, это может быть выполнено с помощью вызова процедуры ERROR_REPORT (см. Раздел 4.2.4.1).

Обсуждение:

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

4.1.3.4 Контрольные суммы UDP

Хост ДОЛЖЕН реализовать средство для генерации и проверки контрольных сумм UDP. Приложение МОЖЕТ при желании иметь возможность контролировать, будет ли сгенерирована контрольная сумма UDP, но оно ДОЛЖНО по умолчанию включать контрольную сумму.

Если дейтаграмма UDP получена с контрольной суммой, отличной от нуля и недействительной, UDP ДОЛЖЕН молча отбросить дейтаграмму. Приложение МОЖЕТ дополнительно иметь возможность контролировать, должны ли дейтаграммы UDP без контрольных сумм отбрасываться или передаваться приложению.

Обсуждение:

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

РЕАЛИЗАЦИЯ:

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

4.1.3.5 UDP Multihoming

Когда принята дейтаграмма UDP, ее адрес конкретного назначения ДОЛЖЕН быть передан на прикладной уровень.

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

Обсуждение:

Приложение запроса / ответа, которое использует UDP, должно использовать исходный адрес для ответа, который совпадает с конкретным адресом назначения запроса. См. Раздел «Общие вопросы» [INTRO: 1].

4.1.3.6 Неверные адреса

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

Когда хост отправляет дейтаграмму UDP, адрес источника ДОЛЖЕН быть (одним из) IP-адресом (ами) хоста.

4.1.4 Интерфейс уровня UDP / APPLICATION

Интерфейс приложения для UDP ДОЛЖЕН предоставлять все услуги интерфейса IP / транспорта, описанного в разделе 3.4 настоящего документа. Таким образом, приложение, использующее UDP, нуждается в функциях вызовов GET_SRCADDR (), GET_MAXSIZES (), ADVISE_DELIVPROB () и RECV_ICMP (), описанных в разделе 3.4. Например, GET_MAXSIZES () может использоваться, чтобы узнать эффективный максимальный максимальный размер дейтаграммы UDP для конкретного триплета {interface, remote host, TOS}.

Программа прикладного уровня ДОЛЖНА иметь возможность устанавливать значения TTL и TOS, а также параметры IP для отправки дейтаграммы UDP, и эти значения должны прозрачно передаваться на уровень IP. UDP МОЖЕТ передать полученное TOS на прикладной уровень.

 

4.1.5 Сводка требований UDP

Порт отправки UDP недоступен (SHOULD — должен)

Параметры IP в UDP
— Передать параметры IP-адреса rcv’d на уровень приложения. (MUST — обязан)
— Прикладной слой может указать параметры IP в Send (MUST — обязан)
— UDP передает параметры IP на уровень IP (MUST — обязан)

Передать сообщения ICMP до уровня приложения (MUST — обязан)

Контрольные суммы UDP:
— Возможность генерировать / проверять контрольную сумму (MUST — обязан)
— молча отменить неверную контрольную сумму (MUST — обязан)
— Опция отправителя, чтобы не генерировать контрольную сумму (MAY — возможна)
— По умолчанию это контрольная сумма (MUST — обязан)
— Опция получателя требует контрольной суммы (MAY — возможна)

UDP Multihoming
— передать spec-dest addr в приложение (MUST — обязан)
— Прикладной уровень может указывать локальный IP-адрес (MUST — обязан)
— Уровень приложения указывает дикий локальный IP-адрес (MUST — обязан)
— Прикладной уровень уведомлен об использовании локального IP-адреса (SHOULD — должен)

Плохой IP src addr молча отбрасывается по UDP / IP (MUST — обязан)
Отправляйте только действительный IP-адрес источника (MUST — обязан)
Службы интерфейса приложений UDP
Полный IP интерфейс 3.4 для приложения (MUST — обязан)
— Возможность спецификации TTL, TOS, IP выбирает при отправке dg (MUST — обязан)
— передать полученный TOS до уровня приложения (MAY — возможна)

4.2 Протокол управления передачей — TCP

4.2.1 Введение

Протокол управления передачей TCP [TCP: 1] является основным транспортным протоколом виртуального канала для пакета Internet. TCP обеспечивает надежную последовательную доставку полнодуплексного потока октетов (8-битных байтов). TCP используется теми приложениями, которым требуется надежная транспортная служба с установлением соединения, например, почта (SMTP), передача файлов (FTP) и служба виртуального терминала (Telnet); Требования к этим протоколам прикладного уровня описаны в [INTRO: 1].

4.2.2 Прохождение протокола

4.2.2.1. Известные порты

Обсуждение:

TCP резервирует номера портов в диапазоне 0-255 для «известных» портов, используемых для доступа к службам, которые стандартизированы через Интернет. Остальная часть пространства порта может быть свободно выделена процессам приложения. Текущие известные определения портов перечислены в RFC под названием «Назначенные номера» [INTRO: 6]. Необходимым условием для определения нового хорошо известного порта является RFC, документирующий предлагаемую услугу достаточно подробно, чтобы разрешить новые реализации.

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

4.2.2.2 Использование Push

Когда приложение отправляет серию вызовов SEND без установки флага PUSH, TCP МОЖЕТ объединять данные внутри системы, не отправляя их. Аналогично, когда серия сегментов принимается без бита PSH, TCP МОЖЕТ поместить данные в очередь, не передавая их принимающему приложению.

Бит PSH не является маркером записи и не зависит от границ сегмента. Передатчик ДОЛЖЕН объединять последовательные биты PSH, когда он пакетирует данные, для отправки максимально возможного сегмента.

TCP МОЖЕТ реализовать флаги PUSH на вызовах SEND. Если флаги PUSH не реализованы, то отправляющий TCP: (1) не должен буферизовать данные бесконечно, и (2) ДОЛЖЕН установить бит PSH в последнем буферизованном сегменте (т. Е. Когда больше нет данных в очереди для отправки).

Обсуждение в RFC-793 на страницах 48, 50 и 74 ошибочно подразумевает, что полученный флаг PSH должен быть передан на прикладной уровень. Передача принятого флага PSH на прикладной уровень теперь НЕОБЯЗАТЕЛЬНА.

Прикладная программа логически обязана устанавливать флаг PUSH в вызове SEND всякий раз, когда ей необходимо форсировать доставку данных, чтобы избежать тупика связи. Однако TCP ДОЛЖЕН отправлять сегмент максимального размера, когда это возможно, для повышения производительности (см. Раздел 4.2.3.4).

Обсуждение:

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

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

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

4.2.2.3 Размер окна

Размер окна ДОЛЖЕН рассматриваться как число без знака, иначе большие размеры окна будут выглядеть как отрицательные окна, и TCP не будет работать. РЕКОМЕНДУЕТСЯ, чтобы реализации резервировали 32-битные поля для размеров окна отправки и получения в записи соединения и выполняли все вычисления окна с 32 битами.

Обсуждение:

Известно, что поле окна в заголовке TCP слишком мало для высокоскоростных путей с большой задержкой. Экспериментальные параметры TCP были определены для расширения размера окна; см. например [TCP: 11]. В ожидании принятия такого расширения разработчики TCP должны рассматривать окна как 32-битные.

4.2.2.4 Срочный указатель

Второе предложение содержит ошибку: указатель срочности указывает на порядковый номер октета LAST (не LAST + 1) в последовательности срочных данных. Описание на странице 56 (последнее предложение) является правильным.

TCP ДОЛЖЕН поддерживать последовательность срочных данных любой длины.

TCP ДОЛЖЕН информировать прикладной уровень асинхронно всякий раз, когда он получает указатель Urgent и ранее не было ожидающих срочных данных, или когда указатель Urgent продвигается в потоке данных. Для приложения ДОЛЖЕН быть способ узнать, сколько срочных данных осталось прочитать из соединения, или, по крайней мере, определить, нужно ли читать более срочные данные.

Обсуждение:

Хотя механизм Urgent может использоваться для любого приложения, он обычно используется для отправки команд типа «прерывание» программе Telnet (см. Раздел «Использование последовательности синхронизации Telnet» в [INTRO: 1]).

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

РЕАЛИЗАЦИЯ:

Родовой вызов ERROR-REPORT (), описанный в разделе 4.2.4.1, является возможным механизмом информирования приложения о поступлении срочных данных.

4.2.2.5 Параметры TCP

TCP ДОЛЖЕН быть в состоянии получить опцию TCP в любом сегменте. TCP ДОЛЖЕН безошибочно игнорировать любую опцию TCP, которую он не реализует, предполагая, что у опции есть поле длины (у всех опций TCP, определенных в будущем, будут поля длины). TCP ДОЛЖЕН быть готов обработать недопустимую длину опции (например, ноль) без сбоя; Предлагаемая процедура — сбросить соединение и записать причину.

4.2.2.6 Опция максимального размера сегмента

TCP ДОЛЖЕН осуществлять отправку и получение параметра «Максимальный размер сегмента» [TCP: 4].

TCP ДОЛЖЕН отправлять опцию MSS (максимальный размер сегмента) в каждом сегменте SYN, когда его принимающая MSS отличается от значения по умолчанию 536, и МОЖЕТ отправлять его всегда.

Если опция MSS не получена при настройке соединения, TCP ДОЛЖЕН принять MSS отправки по умолчанию 536 (576-40) [TCP: 4].

Максимальный размер сегмента, который реально отправляет TCP, «эффективная отправка MSS», ДОЛЖЕН быть меньшим из отправляемой MSS (которая отражает доступный размер буфера повторной сборки на удаленном хосте) и наибольший размер, разрешенный уровнем IP:

Eff.snd.MSS = min(SendMSS+20, MMS_S) — TCPhdrsize — IPoptionsize

где:

* SendMSS — это значение MSS, полученное от удаленного хоста, или значение по умолчанию 536, если опция MSS не получена.
* MMS_S — это максимальный размер сообщения транспортного уровня, которое может отправлять TCP.
* TCPhdrsize — размер заголовка TCP; обычно это 20, но может быть больше, если нужно отправить параметры TCP.
* IPoptionsize — размер любых опций IP, которые TCP будет передавать на уровень IP с текущим сообщением.

Значение MSS для отправки в опции MSS должно быть меньше или равно:

MMS_R — 20

где MMS_R — максимальный размер сообщения транспортного уровня, которое может быть получено (и повторно собрано). TCP получает MMS_R и MMS_S от уровня IP; см. общий вызов GET_MAXSIZES в разделе 3.4.

Обсуждение:

Выбор размера сегмента TCP сильно влияет на производительность. Большие сегменты увеличивают пропускную способность за счет амортизации размера заголовка и затрат на обработку каждой дейтаграммы в большем количестве байтов данных; однако, если пакет настолько велик, что вызывает фрагментацию IP, эффективность резко падает, если какие-либо фрагменты потеряны [IP: 9].

Некоторые реализации TCP отправляют опцию MSS, только если хост назначения находится в не подключенной сети. Однако в целом уровень TCP может не иметь соответствующей информации для принятия этого решения, поэтому предпочтительно оставить на уровне IP задачу определения подходящего MTU для пути в Интернете. Поэтому мы рекомендуем, чтобы TCP всегда отправлял опцию (если не 536) и чтобы уровень IP определял MMS_R, как указано в 3.3.3 и 3.4. Предлагаемый механизм IP-уровня для измерения MTU будет затем изменять IP-уровень без изменения TCP.

4.2.2.7 Контрольная сумма TCP

В отличие от контрольной суммы UDP (см. Раздел 4.1.3.4), контрольная сумма TCP не является обязательной. Отправитель ДОЛЖЕН сгенерировать его, а получатель ДОЛЖЕН проверить.

4.2.2.8 Диаграмма состояния соединения TCP

Есть несколько проблем с этой диаграммой:

(a) Стрелка из SYN-SENT в SYN-RCVD должна быть помечена как «snd SYN, ACK», чтобы согласиться с текстом на странице 68 и с рисунком 8.
(b) Может быть стрелка из состояния SYN-RCVD в состояние LISTEN, обусловленная получением RST после пассивного открытия (см. текстовую страницу 70).
(c) Можно перейти непосредственно из FIN-WAIT-1 в состояние TIME-WAIT (см. стр. 75 спецификации).

4.2.2.9 Выбор начального порядкового номера

TCP ДОЛЖЕН использовать заданный тактовый выбор начальных порядковых номеров.

4.2.2.10 Одновременные открытые попытки

На рисунке 8 есть ошибка: пакет в строке 7 должен быть идентичен пакету в строке 5.

TCP ДОЛЖЕН поддерживать одновременные попытки открытия.

Обсуждение:

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

4.2.2.11 Восстановление из старого дубликата SYN

Обратите внимание, что реализация TCP ДОЛЖНА отслеживать, достигло ли соединение состояния SYN_RCVD в результате пассивного ОТКРЫТИЯ или активного ОТКРЫТИЯ.

4.2.2.12 Сегмент RST

TCP ДОЛЖЕН позволять полученному сегменту RST включать данные.

ОБСУЖДЕНИЕ

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

4.2.2.13 Закрытие соединения

Соединение TCP может завершаться двумя способами: (1) обычная последовательность закрытия TCP с использованием рукопожатия FIN и (2) «прерывание», при котором один или несколько сегментов RST отправляются и состояние соединения немедленно отбрасывается. Если TCP-соединение закрыто удаленным сайтом, локальное приложение ДОЛЖНО быть проинформировано о том, нормально ли оно закрыто или было прервано.

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

Хост МОЖЕТ реализовать полудуплексную последовательность TCP-закрытия, чтобы приложение, вызвавшее CLOSE, не могло продолжить чтение данных из соединения. Если такой хост выполняет вызов CLOSE, когда полученные данные все еще ожидают в TCP, или если новые данные получены после вызова CLOSE, его TCP ДОЛЖЕН послать RST, чтобы показать, что данные были потеряны.

Когда соединение активно закрывается, оно ДОЛЖНО задерживаться в состоянии ВРЕМЯ ОЖИДАНИЯ на время 2xMSL (максимальное время жизни сегмента). Однако он МОЖЕТ принять новый SYN от удаленного TCP, чтобы заново открыть соединение из состояния TIME-WAIT, если он:

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

Обсуждение:

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

Алгоритм изящного закрытия TCP требует, чтобы состояние соединения оставалось определенным (по крайней мере) на одном конце соединения, в течение периода ожидания 2xMSL, то есть 4 минуты. В течение этого периода пара (удаленный сокет, локальный сокет), которая определяет соединение, занята и не может быть повторно использована. Чтобы сократить время связывания данной пары портов, некоторые TCP позволяют принимать новый SYN в состоянии TIME-WAIT.

4.2.2.14 Передача данных

Со времени написания RFC-793 была проведена обширная работа над алгоритмами TCP для достижения эффективного обмена данными. В последующих разделах настоящего документа описываются требуемые и рекомендуемые алгоритмы TCP для определения того, когда отправлять данные (раздел 4.2.3.4), когда отправлять подтверждение (раздел 4.2.3.2) и когда обновлять окно (раздел 4.2.3.3).

Обсуждение:

Одной из важных проблем с производительностью является «синдром глупого окна» или «SWS» [TCP: 5], стабильная схема небольших постепенных перемещений окна, приводящих к крайне низкой производительности TCP. Алгоритмы, позволяющие избежать SWS, описаны ниже как для передающей стороны (раздел 4.2.3.4), так и для принимающей стороны (раздел 4.2.3.3).

Вкратце, SWS вызывается тем, что получатель перемещается по правому краю окна всякий раз, когда у него есть какое-либо новое буферное пространство, доступное для приема данных, и отправителем, использующим любое инкрементное окно, независимо от его размера, для отправки большего количества данных [TCP: 5]. Результатом может быть стабильная схема отправки крошечных сегментов данных, даже если отправитель и получатель имеют большое общее буферное пространство для соединения. SWS может происходить только во время передачи большого количества данных; если соединение перестает работать, проблема исчезнет. Это вызвано типичной простой реализацией управления окнами, но приведенные ниже алгоритмы отправителя и получателя позволят избежать этого.

Еще одна важная проблема производительности TCP заключается в том, что некоторые приложения, особенно удаленный вход в систему для хостов с символьным временем, имеют тенденцию отправлять потоки из однооктетных сегментов данных. Чтобы избежать взаимоблокировок, каждый вызов TCP SEND из таких приложений должен быть «выдвинут» либо явно приложением, либо неявно TCP. Результатом может быть поток сегментов TCP, каждый из которых содержит один октет данных, что очень неэффективно использует Интернет и способствует перегруженности Интернета. Алгоритм Nagle, описанный в разделе 4.2.3.4, обеспечивает простое и эффективное решение этой проблемы. Это имеет эффект объединения символов по соединениям Telnet; это может поначалу удивить пользователей, привыкших к однозначному эхо, но принятие пользователя не было проблемой.

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

Неосторожная реализация может отправлять два или более сегментов подтверждения на каждый полученный сегмент данных. Например, предположим, что получатель немедленно подтверждает каждый сегмент данных. Когда прикладная программа впоследствии использует данные и снова увеличивает доступное пространство буфера приема, получатель может отправить второй сегмент подтверждения, чтобы обновить окно у отправителя. Крайний случай происходит с односимвольными сегментами в соединениях TCP, использующих протокол Telnet для службы удаленного входа. Были отмечены некоторые реализации, в которых каждый входящий 1-символьный сегмент генерирует три возвращаемых сегмента: (1) подтверждение, (2) однобайтовое увеличение в окне и (3) отображаемый символ, соответственно.

4.2.2.15 Время ожидания повторной передачи

В настоящее время известно, что алгоритм, предложенный в RFC-793 для расчета времени ожидания повторной передачи, является недостаточным; см. раздел 4.2.3.1 ниже.

Недавняя работа Джейкобсона [TCP: 7] по перегрузке в Интернете и стабильности повторной передачи TCP позволила создать алгоритм передачи, сочетающий «медленный запуск» с «предотвращением перегрузки». TCP ДОЛЖЕН реализовывать этот алгоритм.

Если повторно переданный пакет идентичен исходному пакету (что подразумевает не только то, что границы данных не изменились, но также и то, что поля окна и подтверждения заголовка не изменились), то МОЖЕТ использоваться то же поле идентификации IP (см. Раздел 3.2.1.5).

РЕАЛИЗАЦИЯ:

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

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

4.2.2.16 Управление окном

Приемник TCP НЕ ДОЛЖЕН сжимать окно, т.е. перемещать правый край окна влево. Тем не менее, отправляющий TCP ДОЛЖЕН быть устойчивым к сжатию окна, что может привести к тому, что «полезное окно» (см. Раздел 4.2.3.4) станет отрицательным.

Если это происходит, отправителю НЕ СЛЕДУЕТ отправлять новые данные, но СЛЕДУЕТ, как правило, повторно передавать старые неподтвержденные данные между SND.UNA и SND.UNA + SND.WND. Отправитель МОЖЕТ также ретранслировать старые данные за пределы SND.UNA + SND.WND, но НЕ ДОЛЖЕН тайм-аут соединения, если данные за правым краем окна не подтверждены. Если окно уменьшается до нуля, TCP ДОЛЖЕН проверить его стандартным способом (см. Следующий раздел).

Обсуждение:

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

4.2.2.17 Зондирование нулевых окон

ДОЛЖНО поддерживаться зондирование нулевых (предлагаемых) окон.

TCP МОЖЕТ держать предложенное окно получения закрытым на неопределенный срок. Пока принимающий TCP продолжает отправлять подтверждения в ответ на сегменты зонда, отправляющий TCP ДОЛЖЕН позволять соединению оставаться открытым.

Обсуждение:

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

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

Передающему хосту СЛЕДУЕТ отправлять первый зонд с нулевым окном, когда для периода ожидания повторной передачи существует нулевое окно (см. Раздел 4.2.2.15), и СЛЕДУЕТ экспоненциально увеличивать интервал между последовательными зондами.

Обсуждение:

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

4.2.2.18 Пассивные вызовы OPEN

Каждый пассивный вызов OPEN либо создает новую запись соединения в состоянии LISTEN, либо возвращает ошибку; это НЕ ДОЛЖНО влиять на ранее созданную запись соединения.

TCP, поддерживающий одновременное использование нескольких пользователей, ДОЛЖЕН предоставить вызов OPEN, который позволит функционально разрешить приложению LISTEN на порт, пока блок соединения с тем же локальным портом находится в состоянии SYN-SENT или SYN-RECEIVED.

Обсуждение:

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

РЕАЛИЗАЦИЯ:

Приемлемые реализации одновременных открытий могут разрешать множественные пассивные вызовы OPEN или могут разрешать «клонирование» соединений с состоянием LISTEN из одного пассивного вызова OPEN.

4.2.2.19 Время жить

В RFC-793 указано, что TCP должен запрашивать уровень IP для отправки сегментов TCP с TTL = 60. Это устарело; значение TTL, используемое для отправки сегментов TCP, ДОЛЖНО быть настраиваемым. См. Раздел 3.2.1.7 для обсуждения.

4.2.2.20 Обработка событий

Хотя это не является строго обязательным, TCP ДОЛЖЕН быть способен ставить в очередь неупорядоченные сегменты TCP. Замените «может» в последнем предложении первого абзаца на странице 70 на «следует».

Обсуждение:

В некоторых реализациях на малых хостах сегментирование очереди было опущено из-за ограниченного буферного пространства. Можно ожидать, что это упущение отрицательно повлияет на пропускную способность TCP, поскольку потеря одного сегмента приводит к тому, что все последующие сегменты выглядят «не в порядке».
В общем, обработка принятых сегментов ДОЛЖНА быть реализована так, чтобы по возможности агрегировать сегменты ACK. Например, если TCP обрабатывает серию сегментов в очереди, он ДОЛЖЕН обработать их все перед отправкой любых сегментов ACK.

Вот некоторые подробные исправления ошибок и примечания к разделу Обработка событий в RFC-793.

(а) ЗАКРЫТЬ Вызов, состояние ЗАКРЫТЬ-ОЖИДАТЬ, с. 61: войти в состояние LAST-ACK, не ЗАКРЫВАЯ.

(b) Состояние LISTEN, проверьте наличие SYN (стр. 65, 66): с помощью бита SYN, если защита / отсек или приоритет неправильны для сегмента, отправляется сброс. Неправильная форма сброса показана в тексте; так должно быть:

<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>

(c) Состояние SYN-SENT, проверка на SYN, p. 68: Когда соединение переходит в состояние ESTABLISHED, должны быть установлены следующие переменные:

SND.WND <- SEG.WND
SND.WL1 <- SEG.SEQ
SND.WL2 <- SEG.ACK

(d) Проверьте безопасность и приоритет, с. 71: Первый заголовок «УСТАНОВЛЕННОЕ СОСТОЯНИЕ» должен быть действительно списком всех состояний, кроме СИН-ПРИНЯТОГО: УСТАНОВЛЕНО, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK и TIME- ПОДОЖДИТЕ.

(e) Проверьте бит SYN, с. 71: «В состоянии SYN-RECEIVED и если соединение было инициировано с пассивным OPEN, верните это соединение в состояние LISTEN и вернитесь. В противном случае …».

(f) Проверьте поле ACK, состояние SYN-RECEIVED, p. 72: Когда соединение переходит в состояние ESTABLISHED, переменные, перечисленные в (c), должны быть установлены.

(g) Проверьте поле ACK, УСТАНОВЛЕННОЕ состояние, p. 72: ACK является дубликатом, если SEG.ACK = <SND.UNA (= было опущено). Аналогично, окно должно быть обновлено, если: SND.UNA = <SEG.ACK = <SND.NXT.

(h) ВРЕМЯ ПОЛЬЗОВАТЕЛЯ, с. 77: было бы лучше уведомить приложение о тайм-ауте, чем позволять TCP принудительно закрывать соединение. Однако см. Также раздел 4.2.3.5.

4.2.2.21. Подтверждение сегментов в очереди

TCP МОЖЕТ отправить сегмент ACK, подтверждающий RCV.NXT, когда поступает действительный сегмент, который находится в окне, но не на левом краю окна.

Обсуждение:

RFC-793 (см. Стр. 74) неоднозначно говорил о том, следует ли отправлять сегмент ACK, когда был получен сегмент не в порядке, т. Е. Когда SEG.SEQ был неравен RCV.NXT.
Одной из причин ACKing сегментов не по порядку может быть поддержка экспериментального алгоритма, известного как «быстрая повторная передача». С помощью этого алгоритма отправитель использует «избыточные» ACK для определения того, что сегмент был потерян до истечения таймера повторной передачи. Он подсчитывает, сколько раз ACK был получен с тем же значением SEG.ACK и с тем же правым краем окна. Если получено больше порогового числа таких ACK, то считается, что сегмент, содержащий октеты, начинающиеся с SEG.ACK, потерян и передается повторно без ожидания тайм-аута. Порог выбран для компенсации максимально вероятного переупорядочения сегмента в Интернете. Пока еще недостаточно опыта работы с алгоритмом быстрой повторной передачи, чтобы определить, насколько он полезен.

 

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

4.2.3.1 Расчет времени ожидания повторной передачи

TCP хост ДОЛЖЕН реализовывать алгоритм Карна и алгоритм Якобсона для вычисления времени ожидания повторной передачи («RTO»).

• Алгоритм Якобсона для вычисления сглаженного времени в оба конца (RTT) включает в себя простую меру дисперсии [TCP: 7].
• Алгоритм Карна для выбора измерений RTT гарантирует, что неоднозначное время кругового обхода не будет искажать расчет сглаженного времени кругового обхода [TCP: 6].

Эта реализация также ДОЛЖНА включать «экспоненциальный откат» для последовательных значений RTO для того же сегмента. Повторная передача сегментов SYN ДОЛЖНА использовать тот же алгоритм, что и сегменты данных.

Обсуждение:

Были две известные проблемы с вычислениями RTO, указанные в RFC-793. Во-первых, точное измерение RTT затруднено при повторных передачах. Во-вторых, алгоритм для вычисления сглаженного времени туда-обратно неадекватен [TCP: 7], потому что он неправильно предполагал, что дисперсия значений RTT будет небольшой и постоянной. Эти проблемы были решены алгоритмом Карна и Якобсона соответственно.

Увеличение производительности в результате использования этих улучшений варьируется от заметного до драматического. Алгоритм Якобсона для включения измеренной дисперсии RTT особенно важен для низкоскоростного канала, где естественное изменение размеров пакетов вызывает большое изменение RTT. Один из поставщиков обнаружил, что использование ссылок на линии размером 9,6 КБ снизилось с 10% до 90% в результате реализации алгоритма дисперсии Якобсона в TCP.

Следующие значения ДОЛЖНЫ использоваться для инициализации параметров оценки для нового соединения:

(а) RTT = 0 секунд.
(б) RTO = 3 секунды. (Сглаженная дисперсия должна быть инициализирована значением, которое приведет к этому RTO).

Известно, что рекомендуемые верхние и нижние границы RTO не подходят для больших интернетов. Нижнюю границу СЛЕДУЕТ измерять в долях секунды (чтобы приспособить высокоскоростные ЛВС), а верхняя граница должна составлять 2 * MSL, то есть 240 секунд.

Обсуждение:

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

4.2.3.2 Когда отправлять сегмент ACK

Хост, который получает поток сегментов данных TCP, может повысить эффективность как в Интернете, так и в хостах, отправив менее одного сегмента ACK (подтверждения) на каждый полученный сегмент данных; это известно как «задержанный ACK» [TCP: 5].

TCP ДОЛЖЕН реализовать отложенный ACK, но ACK не должен быть чрезмерно задержан; в частности, задержка ДОЛЖНА быть менее 0,5 секунды, и в потоке полноразмерных сегментов ДОЛЖЕН быть ACK по меньшей мере для каждого второго сегмента.

Обсуждение:

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

Кроме того, на некоторых крупных многопользовательских хостах задержанный ACK может существенно снизить накладные расходы на обработку протокола за счет уменьшения общего количества пакетов, подлежащих обработке [TCP: 5]. Тем не менее, чрезмерные задержки ACK могут нарушать алгоритмы синхронизации и передачи пакетов в оба конца [TCP: 7].

4.2.3.3 Когда отправлять обновление окна

TCP ДОЛЖЕН включать в приемник алгоритм предотвращения SWS [TCP: 5].

РЕАЛИЗАЦИЯ:

Алгоритм предотвращения SWS получателя определяет, когда правый край окна может быть продвинут; это обычно известно как «обновление окна». Этот алгоритм комбинируется с алгоритмом отложенного ACK (см. Раздел 4.2.3.2), чтобы определить, когда сегмент ACK, содержащий текущее окно, действительно будет отправлен получателю. Мы используем обозначение RFC-793; см. рисунки 4 и 5 в этом документе.

Решение для приемного SWS состоит в том, чтобы избежать продвижения правого края окна RCV.NXT + RCV.WND с небольшими приращениями, даже если данные принимаются из сети небольшими сегментами.

Предположим, что общее пространство буфера приема равно RCV.BUFF. В любой момент октеты RCV.USER этой суммы могут быть связаны с данными, которые были получены и подтверждены, но которые пользовательский процесс еще не использовал. Когда соединение не работает, RCV.WND = RCV.BUFF и RCV.USER = 0.

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

1 — RCV.USER = данные получены, но еще не использованы;
2 — RCV.WND = место, объявленное отправителю;
3 — Reduction = пространство доступно, но еще не объявлено.

Предлагаемый алгоритм предотвращения SWS для приемника должен сохранять фиксированное значение RCV.NXT + RCV.WND до тех пор, пока сокращение не удовлетворит:

RCV.BUFF — RCV.USER — RCV.WND >= min( Fr * RCV.BUFF, Eff.snd.MSS )

где Fr — это дробь, рекомендуемое значение которой равно 1/2, а Eff.snd.MSS — эффективная отправка MSS для соединения (см. раздел 4.2.2.6). Когда неравенство выполнено, RCV.WND устанавливается в RCV.BUFF-RCV.USER.

Обратите внимание, что общий эффект этого алгоритма заключается в продвижении RCV.WND с шагом Eff.snd.MSS (для реалистичных приемных буферов: Eff.snd.MSS <RCV.BUFF / 2). Также обратите внимание, что получатель должен использовать свой собственный Eff.snd.MSS, предполагая, что он совпадает с отправителем.

4.2.3.4 Когда отправлять данные

TCP ДОЛЖЕН включать в отправителя алгоритм избегания SWS.

TCP ДОЛЖЕН реализовывать алгоритм Nagle [TCP: 9] для объединения коротких сегментов. Однако для приложения ДОЛЖЕН быть способ отключить алгоритм Nagle для отдельного соединения. Во всех случаях на отправку данных также распространяется ограничение, налагаемое алгоритмом медленного старта (раздел 4.2.2.15).

Обсуждение:

Алгоритм Nagle, как правило, выглядит следующим образом:

Если есть неподтвержденные данные (т. Е. SND.NXT> SND.UNA), то отправляющий TCP буферизует все пользовательские данные (независимо от бита PSH) до тех пор, пока ожидающие данные не будут подтверждены или пока TCP не сможет отправить полноразмерный сегмент (байты Eff.snd.MSS; см. раздел 4.2.2.6).

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

РЕАЛИЗАЦИЯ:

Алгоритм предотвращения SWS отправителя является более сложным, чем алгоритм получателя, поскольку отправитель не знает (непосредственно) общее буферное пространство получателя RCV.BUFF. Обнаружено, что подход, который хорошо работает, заключается в том, чтобы отправитель вычислял Max (SND.WND), максимальное окно отправки, которое он видел до сих пор в соединении, и использовал это значение в качестве оценки RCV.BUFF. К сожалению, это может быть только оценка; приемник может в любое время уменьшить размер RCV.BUFF. Чтобы избежать возникшей тупиковой ситуации, необходимо иметь тайм-аут для принудительной передачи данных, переопределяя алгоритм предотвращения SWS. На практике это время ожидания должно происходить редко.

«Полезное окно» [TCP: 5]:

U = SND.UNA + SND.WND — SND.NXT

то есть предлагаемое окно меньше объема данных, отправленных, но не подтвержденных. Если D — это объем данных, помещенных в очередь в отправляющем TCP, но еще не отправленных, рекомендуется следующий набор правил.

Отправить данные:

(1) если сегмент максимального размера может быть отправлен, т.е. если:

min(D,U) >= Eff.snd.MSS;

(2) или если данные передаются и все данные из очереди могут быть отправлены сейчас, то есть, если:

[SND.NXT = SND.UNA and] PUSHED and D <= U

(условие в скобках накладывается алгоритмом Нагла);

(3) или если может быть отправлена, по меньшей мере, доля Fs максимального окна, то есть, если:

[SND.NXT = SND.UNA and] min(D.U) >= Fs * Max(SND.WND);

(4) или если данные нажимаются и происходит переопределение тайм-аута.

Здесь Fs — дробь, рекомендуемое значение которой равно 1/2. Время переопределения должно быть в диапазоне 0,1 — 1,0 секунды. Может быть удобно комбинировать этот таймер с таймером, используемым для проверки нулевых окон (Раздел 4.2.2.17).

Наконец, обратите внимание, что только что указанный алгоритм предотвращения SWS должен использоваться вместо алгоритма на стороне отправителя, содержащегося в [TCP: 5].

4.2.3.5 Сбои соединения TCP

Чрезмерная повторная передача одного и того же сегмента по TCP указывает на некоторый сбой удаленного хоста или пути в Интернет. Этот сбой может быть кратким или длительным. Следующая процедура ДОЛЖНА использоваться для обработки чрезмерных повторных передач сегментов данных [IP: 11]:

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

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

(c) Когда количество передач одного и того же сегмента достигает порогового значения R2, превышающего R1, закройте соединение.

(d) Приложение ДОЛЖНО иметь возможность устанавливать значение для R2 для конкретного соединения. Например, интерактивное приложение может установить R2 в «бесконечность», предоставляя пользователю возможность контролировать время отключения.

(d) TCP ДОЛЖЕН сообщить приложению о проблеме доставки (если такая информация не была отключена приложением; см. Раздел 4.2.4.1), когда достигается R1 и до R2. Это позволит прикладной программе удаленного входа (User Telnet), например, информировать пользователя.

Значение R1 ДОЛЖНО соответствовать как минимум 3 повторным передачам при текущем RTO. Значение R2 ДОЛЖНО соответствовать не менее 100 секунд.

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

Повторные передачи SYN ДОЛЖНЫ обрабатываться обычным способом, только что описанным для повторных передач данных, включая уведомление прикладного уровня.
Однако значения R1 и R2 могут отличаться для SYN и сегментов данных. В частности, R2 для сегмента SYN ДОЛЖЕН быть установлен достаточно большим, чтобы обеспечить повторную передачу сегмента в течение по крайней мере 3 минут. Конечно, приложение может закрыть соединение (т.е. отказаться от попытки открытия) раньше.

Обсуждение:

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

4.2.3.6 TCP Keep-Alives

Реализаторы МОГУТ включать «keep-alives» в свои реализации TCP, хотя эта практика не является общепринятой. Если keep-alives включены, приложение ДОЛЖНО иметь возможность включать или выключать их для каждого TCP-соединения, и они ДОЛЖНЫ по умолчанию отключаться.

Пакеты подтверждения активности ДОЛЖНЫ отправляться только в том случае, если в течение определенного интервала не было получено пакетов данных или подтверждений для соединения. Этот интервал ДОЛЖЕН быть настраиваемым и ДОЛЖЕН по умолчанию составлять не менее двух часов.

Чрезвычайно важно помнить, что сегменты ACK, которые не содержат данных, не надежно передаются по TCP. Следовательно, если реализован механизм поддержания активности, он НЕ ДОЛЖЕН интерпретировать отказ отвечать на какой-либо конкретный зонд как обрыв соединения.

Реализация ДОЛЖНА отправить сегмент keep-alive без данных; однако он МОЖЕТ быть конфигурируемым для отправки сегмента keep-alive, содержащего один октет мусора, для совместимости с ошибочными реализациями TCP.

Обсуждение:

Механизм «поддержания активности» периодически проверяет другой конец соединения, когда соединение в противном случае находится в режиме ожидания, даже когда нет данных для отправки. Спецификация TCP не включает механизм keep-alive, поскольку он может: (1) привести к разрыву совершенно хороших соединений во время временных сбоев Интернета; (2) потреблять ненужную полосу пропускания («если никто не использует соединение, кого это волнует, если оно все еще хорошо?»); и (3) стоить денег за интернет-трафик, который взимает плату за пакеты.

Однако некоторые реализации TCP включают механизм поддержки активности. Чтобы подтвердить, что незанятое соединение все еще активно, эти реализации отправляют тестовый сегмент, предназначенный для получения ответа от равноправного TCP. Такой сегмент обычно содержит SEG.SEQ = SND.NXT-1 и может содержать или не содержать один октет мусора данных. Обратите внимание, что при тихом соединении SND.NXT = RCV.NXT, так что этот SEG.SEQ будет за окном. Следовательно, зонд заставляет получателя вернуть сегмент подтверждения, подтверждая, что соединение все еще работает. Если узел разорвал соединение из-за сетевого раздела или сбоя, он ответит RST вместо сегмента подтверждения.

К сожалению, некоторые неправильно реализованные реализации TCP не могут ответить на сегмент с SEG.SEQ = SND.NXT-1, если сегмент не содержит данных. В качестве альтернативы реализация может определить, правильно ли партнер ответил на пакеты поддержки активности без октета данных мусора.

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

4.2.3.7 TCP Multihoming

Если приложение на многосетевом хосте не указывает локальный IP-адрес при активном открытии соединения TCP, TCP ДОЛЖЕН попросить уровень IP выбрать локальный IP-адрес перед отправкой (первого) SYN. См. Функцию GET_SRCADDR () в разделе 3.4.

Во всех других случаях предыдущий сегмент либо был отправлен, либо получен по этому соединению, и TCP ДОЛЖЕН использовать тот же локальный адрес, который использовался в этих предыдущих сегментах.

4.2.3.8 Опции IP

Когда полученные параметры передаются в TCP от уровня IP, TCP ДОЛЖЕН игнорировать параметры, которые он не понимает.

TCP МОЖЕТ поддерживать опции Time Stamp и Record Route.

Приложение ДОЛЖНО иметь возможность указывать исходный маршрут, когда оно активно открывает TCP-соединение, и это ДОЛЖНО иметь приоритет над исходным маршрутом, полученным в дейтаграмме.

Когда TCP-соединение пассивно открывается и пакет приходит с завершенной опцией IP Source Route (содержащей обратный маршрут), TCP ДОЛЖЕН сохранить обратный маршрут и использовать его для всех сегментов, отправленных по этому соединению. Если другой маршрут источника прибывает в более поздний сегмент, более позднее определение ДОЛЖНО переопределить более ранний.

4.2.3.9 ICMP-сообщения

TCP ДОЛЖЕН действовать с сообщением об ошибке ICMP, передаваемым с уровня IP, направляя его к соединению, которое создало ошибку. Необходимая информация о демультиплексировании может быть найдена в заголовке IP, содержащемся в сообщении ICMP.

o Источник гасит

TCP ДОЛЖЕН реагировать на истощение источника, замедляя передачу по соединению. Процедура РЕКОМЕНДУЕТСЯ для того, чтобы Source Quench запускал «медленный старт», как если бы произошел тайм-аут повторной передачи.

o пункт назначения недоступен — коды 0, 1, 5

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

Обсуждение:

TCP может сообщать о состоянии мягкой ошибки непосредственно на прикладной уровень с помощью обратного вызова к процедуре ERROR_REPORT, или он может просто отметить сообщение и сообщить о нем приложению только тогда, когда истечет время ожидания соединения TCP.
o пункт назначения недоступен — коды 2-4

Это серьезные ошибки, поэтому TCP ДОЛЖЕН прервать соединение.

o Превышено время — коды 0, 1

Это должно быть обработано так же, как и целевые недоступные коды 0, 1, 5 (см. Выше).

o Проблема параметров

Это должно быть обработано так же, как и целевые недоступные коды 0, 1, 5 (см. Выше).

4.2.3.10 Удаленная проверка адреса

Реализация TCP ДОЛЖНА отклонить как ошибку локальный вызов OPEN для недопустимого удаленного IP-адреса (например, широковещательный или многоадресный адрес).

Входящий SYN с неверным адресом источника должен игнорироваться TCP или IP-уровнем (см. Раздел 3.2.1.3).

Реализация TCP ДОЛЖНА молча отбрасывать входящий сегмент SYN, который адресован широковещательному или многоадресному адресу.

4.2.3.11. Шаблоны трафика TCP

РЕАЛИЗАЦИЯ:

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

o Односимвольные сегменты

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

o Массовая передача

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

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

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

4.2.3.12 Эффективность

РЕАЛИЗАЦИЯ:

Обширный опыт привел к следующим предложениям для эффективной реализации TCP:

(а) Не копировать данные

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

(б) Ручная работа по проверке контрольной суммы

Хорошая процедура контрольного суммирования TCP обычно в два-пять раз быстрее, чем простая и прямая реализация определения. Часто требуется большая осторожность и продуманное кодирование, чтобы сделать код контрольной суммы «быстрым». См. [TCP: 10].

(c) Код для общего дела

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

4.2.4 Интерфейс уровня TCP / APPLICATION

4.2.4.1 Асинхронные отчеты

НЕОБХОДИМО, чтобы был механизм для сообщения приложению о мягких ошибках TCP. В общем, мы предполагаем, что это принимает форму подпрограммы ERROR_REPORT, предоставляемой приложением, которая может вызываться [INTRO: 7] асинхронно с транспортного уровня:

ERROR_REPORT (имя локального соединения, причина, подзадача) Точное кодирование параметров причины и подзадачи здесь не указывается. Однако условия, которые сообщаются приложению асинхронно, ДОЛЖНЫ включать:

* Пришло сообщение об ошибке ICMP (см. 4.2.3.9)
* Чрезмерные повторные передачи (см. 4.2.3.5)
* Срочное продвижение указателя (см. 4.2.2.4).

Однако прикладная программа, которая не хочет получать такие вызовы ERROR_REPORT, ДОЛЖНА иметь возможность эффективно отключать эти вызовы.

Обсуждение:

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

4.2.4.2 Тип обслуживания

Прикладной уровень ДОЛЖЕН иметь возможность указывать тип обслуживания (TOS) для сегментов, отправляемых по соединению. Это не обязательно, но приложение ДОЛЖНО иметь возможность изменять TOS в течение времени жизни соединения. TCP ДОЛЖЕН передать текущее значение TOS без изменений на уровень IP, когда он отправляет сегменты по соединению.

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

TCP МОЖЕТ передать последнее полученное TOS приложению.

ОБСУЖДЕНИЕ

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

Также обратите внимание, что вызов OPEN, указанный в RFC-793, включает в себя параметр («опции»), в котором вызывающий абонент может указать такие параметры IP, как исходный маршрут, маршрут записи или временная метка.

4.2.4.3 Промывочный звонок

Некоторые реализации TCP включают вызов FLUSH, который очищает очередь отправки TCP любых данных, для которых пользователь отправил вызовы SEND, но все еще находится справа от текущего окна отправки. Таким образом, он сбрасывает столько отправленных данных в очереди, сколько возможно, без потери синхронизации порядкового номера. Это полезно для реализации функции «прервать вывод» в Telnet.

4.2.4.4 Multihoming

Пользовательский интерфейс, описанный в разделах 2.7 и 3.8 RFC-793, должен быть расширен для множественной адресации. Вызов OPEN ДОЛЖЕН иметь необязательный параметр:

OPEN( … [local IP address,] … )

разрешить указание локального IP-адреса.

Обсуждение:

Некоторые приложения на основе TCP должны указывать локальный IP-адрес, который будет использоваться для открытия определенного соединения; FTP является примером.

РЕАЛИЗАЦИЯ:

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

Для активного вызова OPEN будет использоваться указанный параметр «локальный IP-адрес» для открытия соединения. Если параметр не указан, сетевое программное обеспечение выберет соответствующий локальный IP-адрес (см. Раздел 3.3.4.2) для подключения.

4.2.5 Сводка требований TCP

Нажмите флаг
Агрегировать или ставить в очередь необъявленные данные (MAY — возможна)
Отправитель свернуть последовательные флаги PSH (SHOULD — должен)
ОТПРАВИТЬ звонок можно указать НАЖАТЬ (MAY — возможна)
Если не может: отправитель буферирует бесконечно (MUST NOT — не обязан)
Если не можете: PSH последний сегмент (MUST — обязан)
Уведомить о получении ALP PSH (MAY — возможна)
Отправьте сегмент максимального размера, когда это возможно (SHOULD — должен)

Окно
Обрабатывать как число без знака (MUST — обязан)
Обрабатывать как 32-битное число (SHOULD — должен)
Сжать окно справа (SHOULD NOT — не должен)
Надежный против сокращения окна (MUST — обязан)
Окно получателя закрыто на неопределенный срок (MAY — возможна)
Нулевое окно зонда отправителя (MUST — обязан)
Первый зонд после RTO (SHOULD — должен)
Экспоненциальный откат (SHOULD — должен)
Разрешить окну оставаться нулевым бесконечно (MUST — обязан)
Тайм-аут отправителя ОК с нулевым ветром (MUST NOT — не обязан)

Срочные данные
Указатель указывает на последний октет (MUST — обязан)
Последовательность срочных данных произвольной длины (MUST — обязан)
Информировать ALP асинхронно о срочных данных (MUST — обязан) (Примечание 1)
ALP может узнать, если / сколько срочных данных Q’d (MUST — обязан) (Примечание 1)

Параметры TCP
Получить опцию TCP в любом сегменте (MUST — обязан)
Игнорировать неподдерживаемые параметры (MUST — обязан)
Справиться с нелегальным вариантом длины (MUST — обязан)
Реализовать отправку и получение опции MSS (MUST — обязан)
Отправить опцию MSS, если 536 (SHOULD — должен)
Отправлять опцию MSS всегда (MAY — возможна)
Send-MSS по умолчанию 536 (MUST — обязан)
Рассчитать эффективный размер сегмента отправки (MUST — обязан)

Контрольные суммы TCP
Отправитель вычисляет контрольную сумму (MUST — обязан)
Контрольная сумма получателя (MUST — обязан)

Используйте выбор ISN на основе часов (MUST — обязан)

Открытие соединений
Поддержка одновременных попыток открытия (MUST — обязан)
SYN-RCVD запоминает последнее состояние (MUST — обязан)
Пассивный открытый вызов мешает другим (MUST NOT — не обязан)
Функция: симултан. СЛУШАТЬ для того же порта (MUST — обязан)
Запросите IP для src-адреса для SYN, если necc. (MUST — обязан)
В противном случае используйте локальный адрес conn. (MUST — обязан)
ОТКРЫТЬ для широковещательного / многоадресного IP-адреса (MUST NOT — не обязан)
Тихо откажитесь от seg в адрес bcast / mcast (MUST — обязан)

Закрытие соединения
RST может содержать данные (SHOULD — должен)
Информировать приложение об отмене соединения (MUST — обязан)
Полудуплексные соединения (MAY — возможна)
Отправить RST, чтобы указать потерянные данные (SHOULD — должен)
В состоянии ВРЕМЯ ОЖИДАНИЯ в течение 2xMSL секунд (MUST — обязан)
Принять SYN из состояния ВРЕМЯ ОЖИДАНИЯ (MAY — возможна)

Повторные
Алгоритм медленного старта Якобсона (MUST — обязан)
Алгоритм Якобсона (MUST — обязан)
Повторная передача с тем же IP-идентификатором (MAY — возможна)
Алгоритм Карна (MUST — обязан)
Оценка Якобсона RTO alg. (MUST — обязан)
Экспоненциальный откат (MUST — обязан)
SYN RTO рассчитывают так же, как данные (SHOULD — должен)
Рекомендуемые начальные значения и границы (SHOULD — должен)

Генерация ACK:
Сегменты вне очереди (SHOULD — должен)
Обработайте все вопросы перед отправкой ACK (MUST — обязан)
Отправить ACK для сегмента вне заказа (MAY — возможна)
Задержка ACK (SHOULD — должен)
Задержка <0,5 секунд (MUST — обязан)
Каждый второй полноразмерный сегмент ACK’d (MUST — обязан)
Алгоритм обхода приемника SWS (MUST — обязан)

Отправка данных
Конфигурируемый TTL (MUST — обязан)
Алгоритм обхода отправителя SWS (MUST — обязан)
Алгоритм Nagle (SHOULD — должен)
Приложение может отключить алгоритм Nagle (MUST — обязан)

Сбои подключения:
Отрицательный совет по IP на R1 retxs (MUST — обязан)
Закрыть соединение на R2 retxs (MUST — обязан)
ALP может установить R2 (MUST — обязан)
Информировать ALP о R1 <= retxs <R2 (SHOULD — должен)
Рекомендуемые значения для R1, R2 (SHOULD — должен)
Тот же механизм для SYNs (MUST — обязан)
R2 не менее 3 минут для SYN (MUST — обязан)

Отправить пакеты поддержки активности: (MAY — возможна)
— Приложение может запросить (MUST — обязан)
— По умолчанию установлено значение «Выкл.» (MUST — обязан)
— Отправлять только в случае простоя в течение интервала (MUST — обязан)
— Интервал настраивается (MUST — обязан)
— По умолчанию не менее 2 часов. (MUST — обязан)
— Терпимый к потерянным ACK (MUST — обязан)

Опции IP
Игнорировать параметры TCP не понимает (MUST — обязан)
Поддержка Time Stamp (MAY — возможна)
Поддержка записи маршрута (MAY — возможна)
Исходный маршрут:
ALP может указать (MUST — обязан) (Примечание 1)
Переопределяет src rt в дейтаграмме (MUST — обязан)
Построить обратный маршрут от src rt (MUST — обязан)
Позже src переопределяет маршрут (SHOULD — должен)

Получение ICMP-сообщений от IP (MUST — обязан)
Dest. Unreach (0,1,5) => сообщить ALP (SHOULD — должен)
Dest. Unreach (0,1,5) => прервать соединение (MUST NOT — не обязан)
Dest. Unreach (2-4) => прервать соединение (SHOULD — должен)
Source Quench => медленный старт (SHOULD — должен)
Превышено время => сообщить ALP, не прерывать (SHOULD — должен)
Param Problem => сказать ALP, не прерывать (SHOULD — должен)

Проверка адреса
Отклонить ОТКРЫТЫЙ вызов на неверный IP-адрес (MUST — обязан)
Отклонить SYN с неверного IP-адреса (MUST — обязан)
Молча сбросить SYN в адрес bcast / mcast (MUST — обязан)

Сервисы интерфейса TCP / ALP
Механизм сообщения об ошибках (MUST — обязан)
ALP может отключить процедуру отчета об ошибках (SHOULD — должен)
ALP может указать TOS для отправки (MUST — обязан)
Перешли без изменений на IP (SHOULD — должен)
ALP может изменить TOS во время соединения (SHOULD — должен)
Pass получил TOS до ALP (MAY — возможна)
FLUSH вызов (MAY — возможна)
Необязательный локальный IP-адрес. в ОТКРЫТОМ (MUST — обязан)

(MUST — обязан)
(SHOULD — должен)
(MAY — возможна)
(SHOULD NOT — не должен)
(MUST NOT — не обязан)

Сноски:
(1) «ALP» означает программу уровня приложения.

5. Ссылки

[INTRO:1] «Requirements for Internet Hosts — Application and Support,» IETF Host Requirements Working Group, R. Braden, Ed., RFC 1123, October 1989.

[INTRO:2] «Requirements for Internet Gateways,» R. Braden and J. Postel, RFC 1009, June 1987.

[INTRO:3] «DDN Protocol Handbook,» NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985.

[INTRO:4] «Official Internet Protocols,» J. Reynolds and J. Postel, RFC 1011, May 1987. This document is republished periodically with new RFC numbers; the latest version must be used.

[INTRO:5] «Protocol Document Order Information,» O. Jacobsen and J. Postel, RFC 980, March 1986.

[INTRO:6] «Assigned Numbers,» J. Reynolds and J. Postel, RFC 1010, May 1987. This document is republished periodically with new RFC numbers; the latest version must be used.

[INTRO:7] «Modularity and Efficiency in Protocol Implementations,» D. Clark, RFC 817, July 1982.

[INTRO:8] «The Structuring of Systems Using Upcalls,» D. Clark, 10th ACM SOSP, Orcas Island, Washington, December 1985.

Secondary References:

[INTRO:9] «A Protocol for Packet Network Intercommunication,» V. Cerf and R. Kahn, IEEE Transactions on Communication, May 1974.

[INTRO:10] «The ARPA Internet Protocol,» J. Postel, C. Sunshine, and D. Cohen, Computer Networks, Vol. 5, No. 4, July 1981.

[INTRO:11] «The DARPA Internet Protocol Suite,» B. Leiner, J. Postel, R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC,

March 1985. Also in: IEEE Communications Magazine, March 1985. Also available as ISI-RS-85-153.

[INTRO:12] «Final Text of DIS8473, Protocol for Providing the Connectionless Mode Network Service,» ANSI, published as RFC 994, March 1986.

[INTRO:13] «End System to Intermediate System Routing Exchange Protocol,» ANSI X3S3.3, published as RFC 995, April 1986.

LINK LAYER REFERENCES

[LINK:1] «Trailer Encapsulations,» S. Leffler and M. Karels, RFC 893, April 1984.

[LINK:2] «An Ethernet Address Resolution Protocol,» D. Plummer, RFC 826, November 1982.

[LINK:3] «A Standard for the Transmission of IP Datagrams over Ethernet Networks,» C. Hornig, RFC 894, April 1984.

[LINK:4] «A Standard for the Transmission of IP Datagrams over IEEE 802 «Networks,» J. Postel and J. Reynolds, RFC 1042, February 1988. This RFC contains a great deal of information of importance to Internet implementers planning to use IEEE 802 networks.

IP LAYER REFERENCES

[IP:1] «Internet Protocol (IP),» J. Postel, RFC 791, September 1981.

[IP:2] «Internet Control Message Protocol (ICMP),» J. Postel, RFC 792, September 1981.

[IP:3] «Internet Standard Subnetting Procedure,» J. Mogul and J. Postel, RFC 950, August 1985.

[IP:4] «Host Extensions for IP Multicasting,» S. Deering, RFC 1112, August 1989.

[IP:5] «Military Standard Internet Protocol,» MIL-STD-1777, Department of Defense, August 1983.

Эта спецификация с поправками, внесенными RFC 963, предназначена для описания Интернет-протокола, но имеет некоторые серьезные упущения (например, обязательное расширение подсети [IP: 3] и необязательное расширение многоадресной передачи [IP: 4]). Это также устарело. В случае конфликта, RFC 791, RFC 792 и RFC 950 должны считаться авторитетными, в то время как настоящий документ является авторитетным для всех.

[IP:6] «Some Problems with the Specification of the Military Standard Internet Protocol,» D. Sidhu, RFC 963, November 1985.

[IP:7] «The TCP Maximum Segment Size and Related Topics,» J. Postel, RFC 879, November 1983.

Discusses and clarifies the relationship between the TCP Maximum Segment Size option and the IP datagram size.

[IP:8] «Internet Protocol Security Options,» B. Schofield, RFC 1108, October 1989.

[IP:9] «Fragmentation Considered Harmful,» C. Kent and J. Mogul, ACM SIGCOMM-87, August 1987. Published as ACM Comp Comm Review, Vol. 17, no. 5.

This useful paper discusses the problems created by Internet fragmentation and presents alternative solutions.

[IP:10] «IP Datagram Reassembly Algorithms,» D. Clark, RFC 815, July 1982.

This and the following paper should be read by every implementor.

[IP:11] «Fault Isolation and Recovery,» D. Clark, RFC 816, July 1982.

SECONDARY IP REFERENCES:

[IP:12] «Broadcasting Internet Datagrams in the Presence of Subnets,» J. Mogul, RFC 922, October 1984.

[IP:13] «Name, Addresses, Ports, and Routes,» D. Clark, RFC 814, July 1982.

[IP:14] «Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQUID),» W. Prue and J. Postel, RFC 1016, July 1987.

В этом RFC впервые описаны адресные широковещательные адреса. Однако основная часть RFC связана со шлюзами, а не с хостами.

UDP REFERENCES:

[UDP:1] «User Datagram Protocol,» J. Postel, RFC 768, August 1980. TCP REFERENCES:

[TCP:1] «Transmission Control Protocol,» J. Postel, RFC 793, September 1981.

[TCP:2] «Transmission Control Protocol,» MIL-STD-1778, US Department of Defense, August 1984.

This specification as amended by RFC 964 is intended to describe the same protocol as RFC 793 [TCP:1]. If there is a conflict, RFC-793 takes precedence, and the present document is authoritative over both.

[TCP:3] «Some Problems with the Specification of the Military Standard Transmission Control Protocol,» D. Sidhu and T. Blumer, RFC 964, November 1985.

[TCP:4] «The TCP Maximum Segment Size and Related Topics,» J. Postel, RFC 879, November 1983.

[TCP:5] «Window and Acknowledgment Strategy in TCP,» D. Clark, RFC 813, July 1982.

[TCP:6] «Round Trip Time Estimation,» P. Karn & C. Partridge, ACM SIGCOMM-87, August 1987.

[TCP:7] «Congestion Avoidance and Control,» V. Jacobson, ACM SIGCOMM-88, August 1988.

SECONDARY TCP REFERENCES:

[TCP:8] «Modularity and Efficiency in Protocol Implementation,» D. Clark, RFC 817, July 1982.

[TCP:9] «Congestion Control in IP/TCP,» J. Nagle, RFC 896, January 1984.

[TCP:10] «Computing the Internet Checksum,» R. Braden, D. Borman, and C. Partridge, RFC 1071, September 1988.

[TCP:11] «TCP Extensions for Long-Delay Paths,» V. Jacobson & R. Braden, RFC 1072, October 1988.

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

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

Архитектура Интернета, как правило, обеспечивает небольшую защиту от подделки IP-адресов источников, поэтому к любому механизму безопасности, основанному на проверке IP-адреса источника дейтаграммы, следует относиться с подозрением. Однако в ограниченных средах возможна некоторая проверка адреса источника. Например, может существовать защищенная ЛВС, шлюз которой к остальной части Интернета отбрасывает любую входящую дейтаграмму с адресом источника, который подделывает адрес ЛВС. В этом случае хост в локальной сети может использовать адрес источника для проверки локального или удаленного источника. Эта проблема усложняется маршрутизацией от источника, и некоторые считают, что пересылка дейтаграмм с маршрутизацией от источника хостами (см. Раздел 3.3.5) должна быть запрещена из соображений безопасности.

Вопросы, связанные с безопасностью, упоминаются в разделах, касающихся опции IP Security (раздел 3.2.1.8), сообщения о проблеме параметров ICMP (раздел 3.2.2.5), параметров IP в дейтаграммах UDP (раздел 4.1.3.2) и зарезервированных портов TCP (раздел 4.2.2.1).

Адрес автора

Robert Braden
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: (213) 822 1511
EMail: Braden@ISI.EDU