AAA

RFC 791 — Протокол IP (Internet Protocol)

Предисловие

Этот документ содержит спецификацию стандарта DoD (Министерство обороны США) для протокола IP (IP). Документ основан на 6 предварительных вариантах спецификации протокола ARPA Internet и содержит фрагменты этих спецификаций. В разработке используемых в документе концепций и терминологии принимало участие множество людей. В данной редакции пересмотрены вопросы адресации, обработки ошибок, кодирования опций, приоритетов, изоляции (compartments) и ограничений протокола Internet.

Jon Postel, редактор

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

Термин gateway в исходном документе использовался для обозначения устройств, которые сегодня называют маршрутизаторами (router), а термин шлюз (буквальный перевод gateway) обозначает обычно устройства (программы), обеспечивающие преобразование протоколов на более высоких уровнях модели ISO/OSI (например, почтовые шлюзы).

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

Часто встречающийся в исходном документе термин local network interface переводится как 'интерфейс канального уровня», в соответствии с современной терминологией.

Николай Малых, переводчик

Оглавление

1. Введение

1.1. Мотивация

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

1.2. Сфера действия протокола

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

1.3. Интерфейсы

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

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

Для случая ARPANET, например, модуль IP будет вызывать модуль локальной сети, который добавит заголовок типа 1822 [2] к дейтаграмме, создавая сообщение ARPANET для передачи IMP. Адрес ARPANET определяется из адреса IP интерфейсом с локальной сетью и будет принимать значение адреса какого-либо из хостов ARPANET, который может быть шлюзом в другую сеть.

1.4. Работа протокола

Протокол IP выполняет две основных функции — адресацию и фрагментацию/сборку дейтаграмм.

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

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

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

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

Для обеспечения сервиса протокол IP использует 4 ключевых механизма — ToS (тип обслуживания), TTL (время жизни), Options (опции) и Header Checksum (контрольная сумма заголовка).

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

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

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

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

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

При обнаружении ошибок информация о них может передаваться с помощью протокола ICMP (Internet Control Message Protocol) [3], реализуемого в модуле IP.

2. Обзор

2.1. Связь с другими протоколами

На приведенном рисунке (Рисунок 1) показаны связи IP с другими протоколами:

+------+ +-----+ +-----+     +-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+     +-----+
      |   |         |           |
     +-----+     +-----+     +-----+
     | TCP |     | UDP | ... | ... |
     +-----+     +-----+     +-----+
        |           |           |
     +--------------------------+----+
     |           IP & ICMP           |
     +--------------------------+----+
                    |
       +---------------------------+
       |  Протокол локальной сети  |
       +---------------------------+

Рисунок 1. Связь с другими протоколами

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

2.2. Модель работы протокола

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

Будем предполагать что передача включает лишь один промежуточный шлюз.

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

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

Модуль передает дейтаграмму и локальный адрес локальному сетевому интерфейсу.

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

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

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

Прикладная программа                          Прикладная программа
        \                                            /
      модуль IP             модуль IP             модуль IP
          \                 /       \              /
          LNI-1          LNI-1      LNI-2        LNI-2
             \           /            \          /
            Локальная сеть 1         Локальная сеть 2


Рисунок 2. Путь передачи данных

2.3. Функциональное описание

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

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

Адресация

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

Адреса имеют IP фиксированную длину — 4 октета (32 бита). Адрес начинается с номера сети, за которым следует локальный адрес (его называют полем rest — остаток). Существует три класса адресов IP — класс A, в котором старший бит имеет значение 0, остальные 7 битов старшего октета задают номер сети, а 24 младших бита — номер хоста; класс B, в котором два старших бита имеют значения 10, следующие 14 битов определяют номер сети, а последние 16 битов — номер хоста; класс C, в котором три старших бита имеют значения 110, следующие 21 образуют номер сети, а последние 8 битов определяют номер хоста.

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

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

Примеры отображения адресов приводятся в работе Address Mappings [5].

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

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

Дейтаграмма IP может быть помечена как don't fragment (не фрагментировать). Такие дейтаграммы не будут фрагментироваться ни при каких обстоятельствах. Если нефрагментируемая дейтаграмма IP не может быть доставлена адресату без фрагментации, она просто отбрасывается.

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

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

Поле идентификации позволяет различать фрагменты разных дейтаграмм. Отправляющий дейтаграмму модуль протокола устанавливает значение поля идентификации в каждой дейтаграмме так, чтобы оно было уникальным для данной пары отправитель-получатель и протокола в течение времени присутствия дейтаграммы в сети Internet. Этот модуль также устанавливает нулевые значения смещения фрагмента и флага наличия других фрагментов (more-fragments flag).

Для фрагментирования длинной дейтаграммы IP модуль IP (например, на маршрутизаторе) создает две новых дейтаграммы IP и копирует содержимое полей заголовка из длинной дейтаграммы в заголовки обеих новых дейтаграмм. Данные исходной дейтаграммы делятся на две части по 64 битовой (8 октетов) границе. Вторая часть дейтаграммы может иметь размер, не кратный 8 октетам (64 битам), но первая часть должна содержать целое число 8-октетных блоков. Назовем число 8-октетных блоков в первой части дейтаграммы NFB (Number of Fragment Blocks — число блоков фрагментации). Первая часть дейтаграммы помещается в первую из новых дейтаграмм IP и поле длины устанавливается в соответствии длиной первой дейтаграммы. Для первой дейтаграммы устанавливается флаг наличия дополнительных фрагментов. Вторая часть данных помещается во вторую из созданных заново дейтаграмм и поле размера устанавливается в соответствии с длиной новой дейтаграммы. Значение поля смещения увеличивается на величину NFB. Значение флага наличия дополнительных фрагментов сохраняется в соответствии с флагом исходной нефрагментированной дейтаграммы.

Эту процедуру легко обобщить на случай разбиения дейтаграммы на n фрагментов, где n > 2. Для сборки фрагментов дейтаграммы IP, модуль IP (например, на хосте адресата) объединяет дейтаграммы IP с совпадающими значениями полей идентификации, адресов отправителя и получателя, а также протокола. Объединение осуществляется путем размещения данных из каждой дейтаграммы в позицию буфера, указанную полем смещения фрагмента в заголовке IP. Первый фрагмент будет иметь нулевое смещение, а для последнего фрагмента флаг more-fragments будет иметь нулевое значение.

2.4. Шлюзы

Шлюзы обеспечивают пересылку дейтаграмм IP между сетями, обеспечивая также поддержку протокола GGP (Gateway to Gateway Protocol — протокол обмена данными между шлюзами) [7] для обмена данными маршрутизации и другой управляющей информацией.

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

   +------------------------------+
   |        IP + ICMP + GGP       |
   +------------------------------+
          |                 |
+----------------+  +----------------+
| Локальная сеть |  | Локальная сеть |
+----------------+  +----------------+

Рисунок 3. Протоколы шлюзов

3. Спецификация

3.1. Формат заголовка IP

Заголовок дейтаграмм internet имеет следующий формат:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат заголовка дейтаграммы IP

3.2. Обсуждение

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

Базовый сервис internet ориентирован на обработку дейтаграмм и обеспечивает фрагментацию дейтаграмм на шлюзах и сборку фрагментов модулем IP хоста-получателя. Фрагментация и сборка дейтаграмм внутри отдельной сети или на основе частного соглашения также допустимы, поскольку процесс фрагментации и сборки совершенно прозрачен для IP и протоколов вышележащих уровней. Такая прозрачная фрагментация/сборка называется внутрисетевой (network-dependent или intranet) и не рассматривается в данной спецификации.

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

Адресация

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

Формат адресов:

Старшие битыФорматКласс
07 битов задают номер сети, остальные 24 — номер хостаA
1014 битов задают номер сети, остальные 16 — номер хостаB
11021 бит задает номер сети, остальные 8 — номер хостаC
111Используется для расширенной адресации

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

Реальные значения, выделенные для разных групп сетевых адресов указаны в работе Assigned Numbers [9].

Локальные адреса распределяются на уровне локальной сети и должны позволять одному физическому хосту действовать как множество различных хостов internet. Т. е., должно поддерживаться отображение между адресами IP и физическим интерфейсом хоста, позволяющее связать несколько IP-адресов с одним физическим интерфейсом хоста. Должна также поддерживаться и обратная возможность — связывания нескольких физических интерфейсов с одним адресом IP.

Преобразование адресов IP в адреса сетей ARPANET, SATNET, PRNET и т. п. описано в работе Address Mappings [5].

Фрагментация и сборка

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

Флаг наличия других фрагментов (More Fragments или MF) устанавливается для всех фрагментов дейтаграммы, кроме последнего.

Поле Fragment Offset показывает положение фрагмента относительно начала исходной (нефрагментированной) дейтаграммы. Смещение учитывается в блоках размером 8 октетов. Стратегия фрагментации разработана таким образом, чтобы в нефрагментированной дейтаграмме вся поля, связанные с фрагментацией, имели нулевые значения (MF = 0, fragment offset = 0). Если дейтаграмма IP фрагментируется, ее поле данных должно делиться на части по 8-октетным границам.

Таким образом, используемый формат поддерживает до 213 = 8192 фрагментов по 8 октетов (т. е., до 65 536 октетов). Отметим, что это значение соответствует возможным значениям поля размера дейтаграммы в ее заголовке (естественно, заголовок показывает общую длину дейтаграммы, а не ее фрагментов).

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

Каждый модуль IP должен поддерживать пересылку без фрагментации дейтаграмм размером 68 октетов. Это значение выбрано потому, что заголовок дейтаграммы может достигать 60 октетов и поле данных должно содержать, по крайней мере, 8 октетов.

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

При фрагментации могут изменяться следующие поля:

  1. опции
  2. флаг MF
  3. смещение фрагмента
  4. размер заголовка дейтаграммы
  5. общий размер
  6. контрольная сумма заголовка.

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

Процедуры фрагментации и сборки проще описать на примерах. Описанные ниже процедуры содержат примеры реализации. Знак =< в приведенных ниже псевдопрограммах означает «меньше или равно», # — «не равно», = — «равно», <- — «установить значение». Выражение "x - y" включает x и исключает y (например "4 - 7" будет включать числа 4, 5 и 6, но не будет включать 7).

Пример процедуры фрагментации

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

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

Обозначения:

Процедура:

IF TL =< MTU THEN Submit this datagram to the next step
     in datagram processing ELSE IF DF = 1 THEN discard the
datagram ELSE
To produce the first fragment:
(1)  Copy the original internet header;
(2)  OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF;
(3)  NFB <- (MTU-IHL*4)/8;
(4)  Attach the first NFB*8 data octets;
(5)  Correct the header:
     MF <- 1;  TL <- (IHL*4)+(NFB*8);
     Recompute Checksum;
(6)  Submit this fragment to the next step in
     datagram processing;
To produce the second fragment:
(7)  Selectively copy the internet header (some options
     are not copied, see option definitions);
(8)  Append the remaining data;
(9)  Correct the header:
     IHL <- (((OIHL*4)-(length of options not copied))+3)/4;
     TL <- OTL - NFB*8 - (OIHL-IHL)*4);
     FO <- OFO + NFB;  MF <- OMF;  Recompute Checksum;
(10) Submit this fragment to the fragmentation test; DONE.

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

Пример процедуры сборки

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

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

Заголовок первого фрагмента (fragment offset=0) помещается в буфер заголовков. Если фрагмент является последним (MF=0), определяется общий размер дейтаграммы. Если фрагмент завершает прием дейтаграммы (проверяется по таблице блоков), дейтаграмма передается на следующий этап обработки; в противном случае для таймера устанавливается наибольшее из двух значений — текущие показания таймера и значение поля TTL из данного фрагмента; управление передается процедуре сборки фрагментов.

Если заданное таймером время истекло, освобождаются все ресурсы, выделенные для данного идентификатора буфера. Начальная установка таймера задает нижнюю границу времени ожидания при сборке. При получении фрагментов время ожидания может быть увеличено в соответствии с TTL, а уменьшение времени ожидания не предусмотрено. Максимальное The maximum this timer значение таймера совпадает с максимальным значением TTL (около 4,25 мин.). Рекомендуется устанавливать начальное значение таймера равным 15 сек. Эта рекомендация может быть изменена с учетом реального опыт использования протокола. Отметим, что выбор этого значения связан с доступным размером буфера и скоростью среды передачи, т. е., при скорости 10 кбит/с и времени ожидания 15 сек. может потребоваться буфер размером 150 кбит.

Обозначения:

Процедура:

(1)  BUFID <- source|destination|protocol|identification;
(2)  IF FO = 0 AND MF = 0
(3)     THEN IF buffer with BUFID is allocated
(4)             THEN flush all reassembly for this BUFID;
(5)          Submit datagram to next step; DONE.
(6)     ELSE IF no buffer with BUFID is allocated
(7)             THEN allocate reassembly resources
                     with BUFID;
                     TIMER <- TLB; TDL <- 0;
(8)          put data from fragment into data buffer with
             BUFID from octet FO*8 to
                                 octet (TL-(IHL*4))+FO*8;
(9)          set RCVBT bits from FO
                                to FO+((TL-(IHL*4)+7)/8);
(10)         IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11)         IF FO = 0 THEN put header in header buffer
(12)         IF TDL # 0
(13)          AND all RCVBT bits from 0
                                     to (TDL+7)/8 are set
(14)            THEN TL <- TDL+(IHL*4)
(15)                 Submit datagram to next step;
(16)                 free all reassembly resources
                     for this BUFID; DONE.
(17)         TIMER <- MAX(TIMER,TTL);
(18)         give up until next fragment or timer expires;
(19) timer expires: flush all reassembly with this BUFID; DONE.

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

Идентификация

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

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

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

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

ToS

Значение TOS обеспечивает выбор уровня обслуживания с помощью абстрактных параметров precedence (предпочтение, приоритет), delay (задержка), throughput (пропускная способность), reliability (надежность). Эти абстрактные параметры преобразуются в реальные параметры обработки дейтаграмм в сетях на пути доставки.

Например, ARPANET использует бит приоритета и разделяет «стандартные (тип 0) и неконтролируемые (тип 3) сообщения (выбор между одно- и многопакетными сообщениями также может рассматриваться как параметр обслуживания). Неконтролируемые сообщения доставляются с меньшими гарантиями, но имеют более низкую задержку. Предположим, что дейтаграмма IP доставляется через сеть ARPANET с параметрами ToS:

Precedence:5
Delay:0
Throughput:1
Reliability:1

В этом случае отображение параметров сервиса на поддерживаемые в сети ARPANET параметры обслуживания приведет к установке бита приоритета ARPANET, поскольку значение precedence находится в старшей половине возможного диапазона и выбора стандартных сообщений, поскольку заданы параметры throughput и reliability, а бит delay не установлен. Более детальную информацию по этому вопросу можно найти в работе "Service Mappings" [8].

TTL

Значение TTL устанавливается отправителем и задает максимальное время существования дейтаграммы в internet. Если время, заданное полем TTL, истекло, дейтаграмма уничтожается.

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

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

Опции

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

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

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

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

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

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

Ошибки

Сообщения об ошибках протокола IP могут передаваться с использованием протокола ICMP [3].

3.3. Интерфейсы

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

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

Пример интерфейса с вышележащим уровнем

Ниже приведены два примера вызовов, удовлетворяющих требованиям к пользовательским вызовам IP ("=>" означает возврат):

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

  where:

    src = source address
    dst = destination address
    prot = protocol
    TOS = type of service
    TTL = time to live
    BufPTR = buffer pointer
    len = length of buffer
    Id  = Identifier
    DF = Don't Fragment
    opt = option data
    result = response
      OK = datagram sent ok
      Error = error in arguments or local network error

  Note that the precedence is included in the TOS and the
  security/compartment is passed as an option.

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

  where:

    BufPTR = buffer pointer
    prot = protocol
    result = response
      OK = datagram received ok
      Error = error in arguments
    len = length of buffer
    src = source address
    dst = destination address
    TOS = type of service
    opt = option data

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

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

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

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

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

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

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

Приложение A: Примеры и сценарии

Пример 1

Ниже приведен пример минимальной дейтаграммы IP, содержащей данные.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service|        Total Length = 21      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Identification = 111     |Flg=0|   Fragment Offset = 0   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time = 123  |  Protocol = 1 |        header checksum        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         source address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      destination address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     data      |
+-+-+-+-+-+-+-+-+

Рисунок 5. Пример дейтаграммы IP

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

Пример 2

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service|       Total Length = 472      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Identification = 111      |Flg=0|     Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time = 123  | Protocol = 6  |        header checksum        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         source address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      destination address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
\                                                               \
\                                                               \
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             data              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Пример дейтаграммы IP

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service|       Total Length = 276      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Identification = 111      |Flg=1|     Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time = 119  | Protocol = 6  |        Header Checksum        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         source address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      destination address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
\                                                               \
\                                                               \
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Пример фрагмента дейтаграммы IP

Второй фрагмент будет иметь форму.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service|       Total Length = 216      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Identification = 111      |Flg=0|  Fragment Offset  =  32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time = 119  | Protocol = 6  |        Header Checksum        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         source address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      destination address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
\                                                               \
\                                                               \
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            data               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Пример фрагмента дейтаграммы IP

Пример 3

Ниже показан пример дейтаграммы, содержащей опции:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 8 |Type of Service|       Total Length = 576      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Identification = 111    |Flg=0|     Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time = 123  |  Protocol = 6 |       Header Checksum         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        source address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      destination address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = x | Opt.  Len.= 3 | option value  | Opt. Code = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Len. = 4 |           option value        | Opt. Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = y | Opt. Len. = 3 |  option value | Opt. Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
\                                                               \
\                                                               \
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             data                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Пример дейтаграммы IP

Приложение B: Порядок передачи данных

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       1       |       2       |       3       |       4       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       5       |       6       |       7       |       8       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       9       |      10       |      11       |      12       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Порядок передачи байтов.

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

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+

Рисунок 11. Значимость битов

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

Глоссарий

Литература

  1. Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.
  2. Bolt Beranek and Newman, "Specification for the Interconnection of a Host and an IMP," BBN Technical Report 1822, Revised May 1978.
  3. Postel, J., "Internet Control Message Protocol — DARPA Internet Program Protocol Specification," RFC 792, USC/Information Sciences Institute, September 1981
  4. Shoch, J., "Inter-Network Naming, Addressing, and Routing," COMPCON, IEEE Computer Society, Fall 1978.
  5. Postel, J., "Address Mappings," RFC 796, USC/Information Sciences Institute, September 1981.
  6. Shoch, J., "Packet Fragmentation in Inter-Network Protocols," Computer Networks, v. 3, n. 1, February 1979.
  7. Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979.
  8. Postel, J., "Service Mappings," RFC 795, USC/Information Sciences Institute, September 1981.
  9. Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences Institute, September 1981.

Перевод на русский язык

Николай Малых, nmalykh@bilim.com