Министерство образования и науки Республики Казахстан
Казахский национальный технический университет имени К.И.Сатпаева
Кафедра вычислительной техники
Протокол IP
Выполнил: ст. гр. ВПбВ-04-05р
Хаймульдинова Г.К.
Проверила: ст. преп. Мусина Р.Ж.
Алматы 2007
Содержание
Предисловие 3
- Введение 4
1.1 Обоснование 4
1.2 Цель 4
1.3 Интерфейсы 4
1.4 Действие 4
- Обзор 5
2.1 Связь с другими протоколами 5
2.2 Сценарий работы 6
2.3 Описание функций 6
2.4 Шлюзы 8
- Спецификация 8
3.1 Формат заголовка Internet 8
3.2 Обсуждение 16
3.3 Интерфейсы 21
Приложение А: Примеры и сценарии 23
Приложение Б: Порядок передачи данных 25
Толковый словарь 26
Ссылки 28
Предисловие
Данный документ устанавливает Internet протокол в стандарте DOD. Он основан на шести предыдущих версиях спецификации протокола ARPA Internet, и из них в значительной степени заимствован его текст. Вместе с тем в эту работу внесены многие изменения, касающиеся как терминологии, так и собственно изложения материала. Это издание освещает адресацию, обработку ошибок, коды опций, а также безопасность, историю и поддержку свойств протокола Internet.
Джон Постел (Jon Postel)
Редактор
Протокол Internet
Программа DARPA Internet
Спецификация протокола
- Введение
1.1 Обоснование
Протокол Internet создан для использования в объединенных системах компьютерных коммуникационных сетей с коммутацией пакетов. Такие системы были названы «catenet» [1]. Протокол Internet обеспечивает передачу блоков данных, называемых датаграммами, от отправителя к получателям, где отправители и получатели являются хост-компьютерами, идентифицируемыми адресами фиксированной длины. Протокол Internet
обеспечивает при необходимости также фрагментацию и сборку датаграмм для передачи данных через сети с малым размером пакетов.
1.2 Цель
Протокол Internet специально ограничен задачами обеспечения функций, необходимых для передачи битового пакета (датаграммы Internet) от отправителя к получателю через объединенную систему компьютерных сетей. Нет механизмов для увеличения достоверности конечных данных, управления протоколом, синхронизации или других услуг, обычно приненяемых в протоколах передачи от хоста к хосту. Протокол Ineternet может обобщить услуги поддерживающих его сетей с целью предоставления услуг различных типов и качеств.
1.3 Интерфейсы
Данный протокол получил название в соответствии с протоколами передачи информации между хост-компьютерами в межсетевой среде. Протокол вызывает в локальной сети протоколы для передачи датаграммы Internet на следующий шлюз или хост-получатель.
Например, модуль TCP вызывал бы модуль Internet с тем, чтобы получить сегмент TCP (включая заголовок TCP и данные пользователя) как информационную часть Internet пакета. Модуль TCP обеспечил бы адреса и другие параметры в заголовке модуля Internet в качестве параметров рассматриваемого вызова. Модуль Internet в этом случае создал бы датаграмму Internet и прибегнул бы к услугам локальной сети для передачи датаграммы Internet.
Например, в случае сети ARPANET модуль Ineternet вызывал бы локальный сетевой модуль, который бы добавлял к датаграмме Internet проводник типа 1822 [2], создавая сообщение ARPANET для передачи на IMP. Адрес ARPANET получился бы из адреса Intenet с помощью интерфейса локальной сети и относился бы к некоторому хост-компьютеру в сети ARPANET, который мог бы быть шлюзом в другие сети.
1.4 Действие
Протокол Internet выполняет две главные функции: адресацию и фрагментацию.
Модули Internet используют адреса, помещенные в заголовок Internet, для передачи Internet датаграмм их получателям. Выбор пути передачи называется маршрутизацией.
Модули Internet используют поля в заголовке Internet для фрагментации и восстановления датаграмм Internet, когда это необходимо для их передачи через сети с малым размером пакетов.
Сценарий действия состоит в том, что модуль Internet меняет размер на каждом из хостов, задействованных в internet-коммуникации и на каждом из шлюзов, обеспечивающих взаимодействие между сетями. Эти модули придерживаются общих правил для интерпретации полей адресов, для фрагментации и сборки Internet датаграмм. Кроме этого, данные модули (и особенно шлюзы) имеют процедуры для принятия решений о маршрутизации, а также другие функции.
Протокол Internet обрабатывает каждую Internet датаграмму как независимую единицу, не имеющую связи ни с какими другими датаграммами Internet. Протокол не имеет дело ни с соединениями, ни с логическими цепочками (виртуальными или какими-либо другими).
Протокол Internet использует четыре ключевых механизма для формирования своих услуг: задание типа сервиса, времени жизни, опций и контрольной суммы заголовка.
Тип обслуживания используется для обозначения требуемой услуги. Тип обслуживания — это абстрактный или обобщенный набор параметров, который характеризует набор услуг, предоставляемых сетями, и составляющих собственно протокол Internet. Этот способ обозначения услуг должен использоваться шлюзами для выбора рабочих параметров передачи в конкретной сети, для выбора сети, используемой при следующем переходе датаграммы, для выбора следующего шлюза при маршрутизации сетевой Internet датаграммы.
Механизм времени жизни служит для указания верхнего предела времени жизни Internet датаграммы. Этот параметр устанавливается отправителем датаграммы и уменьшается в каждой точке на проходимом датаграммой маршруте. Если параметр времени жизни станет нулевым до того, как Internet датаграмма достигнет получателя, эта датаграмма будет уничтожена. Время жизни можно рассматривать как часовой механизм самоуничтожения.
Механизм опций предоставляет функции управления, которые являются необходимыми или просто полезными при определенных ситуациях, однако он ненужен при обычных комминикациях. Механизм опций предоставляет такие возможности, как временные штампы, безопасность, специальная маршрутизация.
Контрольная сумма заголовка обеспечивает проверку того, что информация, используемая для обработки датаграмм Internet, передана правильно. Данные могут содержать ошибки. Если контрольная сумма неверна, то Internet датаграмма будет разрушена, как только ошибка будет обнаружена.
Протокол Internet не обеспечивает надежности коммуникации. Не имеется механизма подтверждений ни между отправителем и получателем, ни между хост-компьютерами. Не имеется контроля ошибок для поля данных, только контрольная сумма для заголовка. Не поддерживается повторная передача, нет управления потоком.
Обнаруженные ошибки могут быть оглашены посредством протокола ICMP (Internet Control Message Protocol) [3], который поддерживается модулем Internet протокола.
- Обзор
2.1 Связь с другими протоколами
Следующая диаграмма иллюстрирует место протокола Internet в иерархии протоколов.
+——+ +——+ +——+ +——+
|Telnet| | FTP | | TFTP | … | … |
+——+ +——+ +——+ +——+
| | | |
+——+ +——+ +——+
| TCP | | UDP | … | … |
+——+ +——+ +——+
| | |
+—————————+
| Internet Protocol & ICMP |
+—————————+
|
+————————+
| Local Network Protocol |
+————————+
Рис. 1 Взаимодействие протоколов
Протокол Internet взаимодействует с одной стороны с протоколами передачи информации между хост-компьютерами, а с другой — с протоколами локальной компьютерной сети. При этом локальная сеть может являться малой компьютерной сетью, участвующей в создании большой сети, такой как ARPANET.
2.2 Сценарий работы
Схему действий для передачи датаграммы от одной прикладной программы к другой можно проиллюстрировать следующим образом:
Предположим, что перенос будет включать прохождение одного промежуточного шлюза. Отправляющая прикладная программа готовит свои данные и вызывает свой локальный Internet модуль для отправки этих данных в качестве датаграммы, а в качестве аргументов этого вызова передает адрес получателя и другие параметры.
Модуль Internet готовит заголовок датаграммы и стыкует с ним данные. Модуль Internet определяет локальный сетевой адрес, соответствующий данному адресу Internet. В данном случае это адрес шлюза.
Модуль передает данную датаграмму и адрес в локальной сети в распоряжение интерфейса локальной сети.
Интерфейс локальной сети создает соответствующий этой сети заголовок и соединяет с ним датаграмму. Затем он передает по локальной сети полученный таким образом результат.
Датаграмма достигает хост-компьютер, играющий роль шлюза и расположенный в вершине сети. Интерфейс локальной сети отделяет этот заголовок и передает датаграмму на модуль Internet. Модуль Internet определяет из Internet адреса, что датаграмма должна быть направлена на хост-компьютер во второй сети. Модуль Internet определяет адрес хоста-получателя в локальной сети. Он обращается к интерфейсу локальной сети с тем, чтобы она переслала данную датаграмму по назначению.
Интерфейс создает заголовок локальной сети и соединяет с ним датаграмму, а затем результат на правляет на хост-получатель.
На хосте-получателе интерфейс локальной сети удалает заголовок локальной сети и передает оставшееся на Internet модуль.
Модуль Internet определяет, что рассматриваемая выше датаграмма предназначена для прикладной программы на этот хосте. Модуль передает данные прикладной программе в ответ на системный вызов. В качестве результата этого вызова передаются адрес получателя и другие параметры.
прикладная программа прикладная программа
\ /
модуль Internet модуль Internet модуль Internet
\ / \ /
LNI-1 LNI-1 LNI-2 LNI2
\ / \ /
локальная сеть 1 локальная сеть 2
Рис. 2 Путь передачи датаграммы
2.3 Описание функций
Функция или цель протокола Internet состоит в передаче датаграммы через набор объединенных компьютерных сетей. Это осуществляется посредством передачи датаграмм от одного модуля Internet к другому до тех пор, пока не будет достигнут получатель. Модули Internet находятся на хостах и шлюзах системы Internet. Датаграммы направляются с одного модуля Internet на другой через конкретные компьютерные сети, основанные на интерпретации Internet адресов. Таким образом, одним из важных механизмов протокола Internet является Internet адрес.
При передаче сообщений с одного Internet модуля на другой датаграммы могут нуждаться в прохождении через сети, для которых максимальный размер пакета меньше, чем размер датаграммы. Чтобы преодолеть эту сложность, в протокол Internet включен механизм фрагментации.
Адресация. В протоколе сделано разграничение между именами, адресами и маршрутами [4]. Имя показывает искомый нами объект. Адрес показывает его местонахождение. Internet имеет дело с адресами. Перевод имен в адреса является задачей протоколов более высокого уровня (прикладных программ или протоколов передачи синхронизации с хоста на хост). Собственно модуль Internet осуществляет отображение адресов Internet на адреса локальной сети. Создание карты адресов локальной сети для получения маршрутов — задача процедур более низкого уровня (процедур локальной сети или шлюзов).
Адреса имеют фиксированную длину четыре октета (32 бита). Адрес начинается с сетевого номера, за которым следует локальный адрес (называемый полем остатка «rest»). Существуют три формата или класса адресов Internet. В классе a самый старший бит нулевой. Следующие 7 бит определяют сеть. а последние 24 бита — локальный адрес. В классе b самые старшие два бита равны соответственно 1 и 0, следующие 14 бит определяют сеть, а последние 16 бит — локальный адрес. В классе c три самых старших бита равны соответственно 1,1 и 0, следующие 21 бит определяют сеть, а последние 8 бит — локальный адрес.
При отображении карты Internet адресов на адреса локальной сети следует соблюдать осторожность. Единичный хост-компьютер должен уметь работать так, как если бы на его месте существовало несколько отдельных хост-компьютеров для использования нескольких адресов Internet. Некоторые хост-компьютеры будут также иметь несколько физических интерфейсов (multi-homing).
Таким образом, следует обеспечить каждый хост-компьютер несколькими физическими сетевыми интерфейсами, имеющими по несколько логических адресов Internet.
Примеры построения карты адресов можно найти в документе «Address Mapping» [5].
Фрагментация. Фрагментация Internet датаграммы необходима, когда эта датаграмма возникает в локальной сети, позволяющей работать с пакетами большого размера, и затем должна пройти к получателю через другую локальную сеть, которая ограничивает пакеты меньшим размером.
Internet датаграмма может быть помечена как нефрагментируемая. Любая Internet датаграмма, помеченная таким образом, не может быть фрагментирована модулем Internet ни при каких условиях. Если же Internet датаграмма, помеченная как нефрагментируемая, тем не менее не может достигнуть получателя без фрагментации, то вместо этого она будет разрушена.
Фрагментация, перенос и сборка в локальной сети, невидимые для модуля Internet протокола, называются внутрисетевой фрагментацией и могут быть всегда использованы [6].
Необходимо, чтобы Internet процедуры фрагментации и сборки могли разбивать датаграмму на почти любое количество частей, которые впоследствии могли бы быть вновь собраны. Получатель фрагмента использует поле идентификации для того, чтобы быть убежденным в том, что фрагменты различных датаграмм не будут перепутаны. Поле смещения фрагмента сообщает получателю положение фрагмента в исходной датаграмме. Смещение фрагмента и длина определяют кусок исходной датаграммы, принесенный этим фрагментом. Флаг «more fragments» показывает (посредством перезагрузки) появление последнего фрагмента. Эти поля дают достаточное количество информации для сборки датаграмм.
Поле идентификации позволяет отличить фрагменты одной датаграммы от фрагментов другой. Модуль Internet, отправляющий Internet датаграмму, устанавливает в поле идентификации значение, которое должно быть уникальным для данной пары отправитель — получатель, а также время, в течении которого датаграмма будет активна в системе Internet. Модуль протокола, отправляющий нерасчлененную датаграмму, устанавливает в нуль флаг «more fragments» и смещение во фрагменте.
Чтобы расчленить большую Internet датаграмму, модуль протокола Internet (например, шлюз), создает две новые Intenet датаграммы и копирует содержимое полей Internet заголовка из большой датаграммы в оба новых Internet заголовка. Данные из старой датаграммы делятся на две части по границе на очередном восьмом октете (64 бита). Полученная таким образом вторая часть может быть кратна 8 октетам, а может и не быть, но первая часть кратна всегда. Заказывается количество блоков первой части NFB (количество блоков фрагмента). Первая часть данных помещается в первую новую Internet датаграмму, в поле общей длины помещается длина первой датаграммы. Флаг «more fragments» устанавливается в единицу. Вторая часть данных помещается во вторую новообразованную Internet датаграмму, в поле общей длины заносится длина второй датаграммы. В поле смещения фрагмента во второй Internet датаграмме устанавливается значение такого же поля в исходной большой датаграмме, увеличенное на NFB.
Эта процедура может быть обобщена на случай многократного расщепления исходной датаграммы.
Чтобы собрать фрагменты Internet датаграммы, модуль протокола Internet (например, модуль на хост-компьютере) объединяет Internet датаграммы, имеющие одинаковые значения в полях идентификатора, отправителя, получателя и протокола. Собственно объединение заключается в помещении данных из каждого фрагмента в позицию, указанную в заголовке Internet пакета в поле «fragment offset». Первый фрагмент будет иметь в поле «fragment offset» нулевое значение, а последний фрагмент будет иметь флаг «more fragments», вновь установленный в нуль.
2.4 Шлюзы
С помощью шлюзов протокол Internet осуществляет передачу датаграмм между сетями. Шлюзы также поддерживают протокол шлюз-шлюз (GGR) [7] для координации маршрутизации и передачи другой управляющей информации для протокола Internet.
Нет нужды держать на шлюзе протоколы более высокого уровня, а функции GGP добавляются к возможностям IP модуля.
+———————————+
| Internet протокол & ICMP & GGP |
+———————————+
| |
+—————-+ +—————-+
| локальная сеть | | локальная сеть |
+—————-+ +—————-+
Рис. 3 Протоколы шлюзов
- Специфиация
3.1 Формат заголовка Internet
Ниже приведена полная схема полей заголовка Internet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рис. 4 Пример заголовка Internet датаграммы
Заметим, что каждая позиция соответствует одному биту.
Version (версия) 4 бита
Поле версии показывает формат заголовка Internet. Данный документ описывает версию 4.
IHL (длина Internet заголовка) 4 бита
Длина Internet заголовка измеряется в словах по 32 бита каждый и указывает на начало поля данных. Заметим, что корректный заголовок может иметь минимальный размер 5 слов.
Type of Service (тип сервиса) 8 бит
Тип сервиса определяет с помощью неких абстрактных параметров тип требуемого обслуживания. Эти параметры должны использоваться для управления выбором реальных рабочих характеристик при передаче датаграммы через конкретную сеть. Некоторые сети осуществляют обслуживание с приоритетом, которое неким образом дает преимущество для продвижения данной датаграммы по сравнению со всеми остальными.
Реально выбор осуществляется между тремя альтернативами: малой задержкой, высокой достоверностью и высокой пропускной способностью.
биты 0-2 приоритет
бит 3 0 — нормальная задержка, 1 — малая задержка
бит 4 0 — нормальная пропускная способность, 1 — высокая пропускная способность
бит 5 0 — обычная достоверность, 1 — высокая достоверность
биты 6-7 зарезервированы
0 1 2 3 4 5 6 7
+——+——+——+——+——+——+——+——+
| приоритет | D | T | R | 0 | 0 |
+——+——+——+——+——+——+——+——+
Приоритет
111 — управление сетью
110 — межсетевое управление
101 — CRITIC/ECP
100 — более, чем мгновенно
011 — мгновенно
010 — немедленно
001 — приоритетно
000 — обычный маршрут
Использование индикации задержки, пропускной способности и
достоверности может, в некотором смысле, увеличить стоимость
обслуживания. Во многих сетях улучшение одного из этих параметров
связано с ухудшением другого. Исключения, когда имело бы смысл
устанавливать два из этих трех параметров, очень редки.
Тип обслуживания используется для указания типа обработки
датаграммы при ее прохождении через систему Internet. Примеры
отображения типа обслуживания в протоколе Internet на реальные
услуги, предоставляемые такими сетями, как AUTODIN II, ARPANET,
SATNET и PRNET даны в документе «Service Mapping» [8]. Значение
«управление сетью» следует присваивать приоритету только для
использования внутри локальной сети. Управление и реальное
использование этого аргумента должно находиться в согласии с каждой
применяющей его сетью. Аргумент «межсетевое управление» предназначен
только для использования шлюзами, берущими на себя управление. Если
вышеописанные аргументы приоритета находят применение в какой-либо
сети, то это означает, что данная сеть может управлять приемом и
использованием этих аргументов.
Total Length (общая длина) 16 бит
Общая длина — это длина датаграммы, измеренная в октетах, включая
Internet заголовок и поле данных. Это поле может задавать длину
датаграммы вплоть до 65535 октетов. В большинстве хост-компьютеров и
сетей столь большие датаграммы не используются. Все хосты должны быть
готовы принимать датаграммы вплоть до 576 октетов длиной (приходят ли
они целиком или по фрагментам). Хостам рекомендуется отправлять
датаграммы размером более чем 576 октетов, только если они уверены,
что принимающий хост готов обслуживать датаграммы повышенного
размера.
Значение 576 выбрано с тем, чтобы соответсвующим образом
ограниченный блок данных передавался вместе с требуемой информацией в
заголовке. Например, этот размер позволяет заполнять датаграмму полем
данных размером в 512 октетов и заголовком в 64 октета. Наибольший
Internet заголовок занимает 60 октетов, а его типичный размер
составляет всего 20 октетов, что оставляет место под заголовки
протоколов более высокого уровня.
Identification (идентификатор) 16 бит
Идентификатор устанавливается отправителеим для сборки фрагментов
какой-либо датаграммы.
Flags (различные управляющие флаги) 16 бит
бит 0 зарезервирован, должен быть нуль
бит 1 (DF) 0 — возможно фрагментирование, 1 — запрет фрагментации
бит 2 (MF) 0 — последний фрагмент, 1 — будут еще фрагменты
0 1 2
+—-+—-+—-+
| 0 | DF | MF |
+—-+—-+—-+
Fragment Offset (смещение фрагмента) 13 бит
Это поле показывает, где в датаграмме находится этот фрагмент.
Смещение фрагмента изменяется порциями по 8 октет (64 бита). Первый
фрагмент имеет смещение нуль.
Time to Live (Время жизни) 8 бит
Это поле показывает максимальное время, в течении которого датаграмме
позволено находиться в системе Internet. Если это поле имеет значение
нуль, то датаграмма должна быть разрушена. Значение этого поля
изменяется при обработке заголовка Internet. Время измеряется в
секундах. Однако, поскольку каждый модуль, обрабатывающий датаграмму,
должен уменьшать значение поля TTL по крайней мере на единицу, даже
если он обрабатываетт эту датаграмму менне, чем за секунду, то поле
TTL следует понимать как максимальный интервал времени, в течении
которого датаграмма может сущенствовать. Внимание следует обратить на
разрушение датаграмм, не могущих достигнуть получателя, а также на
ограничение времени жизни датаграммы.
Protocol (Протокол) 8 бит
Это поле показывает, какой протокол следующего уровня использует
данные из Internet датаграммы. Значения для различных протоколов
приводятся в документе «Assigned Numbers» [9].
Header Checksum (Контрольная сумма заголовка) 16 бит
Поскольку некоторые поля заголовка меняют свое значение (например,
время жизни), это значение проверяется и повторно рассчитывается при
каждой обработке Internet заголовка.
Алгоритм контрольной суммы следующий:
Поле контрольной суммы — это 16 бит, дополняющие биты в сумме всех
16 битовых слов заголовка. Для вычисления контрольной суммы
значение этого поля устанавливается в нуль.
Контрольную сумму легко рассчитать и опытным путем доказать ее
адекватность, однако это временная мера и должна быть заменена CRC
процедурой в зависимости от дальнейшего опыта.
Source Address (адрес отправителя) 32 бита (см. часть 3.2)
Destination Address (адрес получателя) 32 бита (см. часть 3.2)
Options (опции) поле переменной длины
Опции могут появиться в датаграммах, а могут и не появляться. Они
должны поддерживаться всеми Internet модулями (хостами и шлюзами).
Не обязательно каждая конкретная датаграмма несет опции, но нести их
все же может.
В некоторых приложениях опция секретности должна присутствовать во
всех датаграммах.
Поле опций не имеет постояннойц длины. Опций может не быть, а может
быть несколько. Существуют два формата опции:
— единичный октет с указанием типа опции
— единичный октет с указанием типа опции, октет для указания длины
опции, и, наконец, октеты собственно данных.
Октет длины поля учитывает октет типа опции, сам себя и октеты с
данными для опции.
Считается, что октет типа опции состоит из трех полей:
1 бит флаг копирования
2 бита класс опции
5 бит номер опции
Флаг копирования показывает, что эта опция копируется во все
фрагменты при фрагментации.
0 — не копируется
1 — копируется
Классы опции
0 — управление
1 — резервировано
2 — отладка и измерения
3 — резервировано
Определены следующие опции Internet
класс номер длина описание
0 0 — Конец списка опций. Эта опция занимает лишь один
октет, октет длины отсутствует.
0 1 — Нет операции. Эта опция занимает лишь один октет.
Не имеет октета длины.
0 2 11 Безопасность. Используется для поддержания
безопасности, изоляции, разделения на группы
пользователей (TCC), обработки кодов ограничения,
соответсвующих DOD требованиям.
0 3 перем Потеря маршрута отправителя. Используется для
передачи Internet датаграммы, основанной на
имеющейся у отправителя информации
0 9 перем Определение маршрута отправителя. Используется для
передачи Internet датаграммы, основанной на
имеющейся у отправителя информации
0 7 перем Запись маршрута. Используется для отслеживания
проходимого Internet датаграммой маршрута.
0 8 4 Идентификатор маршрута. Используется для поддержки
идентификации потока.
2 4 перем Временной штамп Internet.
Отдельные описания опций
+———+
Тип 0 |00000000| End of Option List (конец списка опций)
+———+
Эта опция обозначает конец списка опций. Он может не совпадать с окончанием Internet заголовка, обозначаемым полем Internet header length. Эта опция используется после всех опций, но не после каждой. Она необходима только в том случае, если конец списка опций не совпал с окончанием Internet заголовка. Может быть скопирован, внесен или удален при фрагментации, или по какой-либо другой причине.
+———+
Тип 1 |00000001| No operation (нет действий)
+———+
Эта опция может быть использована между другими опциями. Ее целью может служить, к примеру, выравнивание очередной опции по 32- битной границе. Может быть скопирована, внесена или удалена при фрагментации и по любой другой причине.
Тип 130 Security (безопасность)
Эта опция дает способ хост-компьютерам отправлять параметры, связанные с безопасностью, закрытостью, введением ограничений и параметрами TCC (закрытой группой пользователей). Формат этой опции следующий: (длина 11 октетов)
+———+———+—///—+—///—+—///—+—///—-+
|10000010|00001011|SSS…SSS|CCC…CCC|HHH…HHH| TCC |
+———+———+—///—+—///—+—///—+—///—-+
Поле S (security) 16 бит
Указывает один из 16 уровней безопасности (восемь из которых
зарезервировано).
00000000 00000000 — неклассифицировано
11110001 00110101 — конфиденциальный
01111000 10011010 — EFTO
10111100 01001101 — MMMM
01011110 00100110 — PROG
10101111 00010011 — ограниченный
11010111 10001000 — секретный
01101011 11000101 — особо секретный
00110101 11100010 — резервировано
10011010 11110001 — резервировано
01001101 01111000 — резервировано
00100100 10111101 — резервировано
00010011 01011110 — резервировано
10001001 10101111 — резервировано
11000100 11010110 — резервировано
11100010 01101011 — резервировано
Поле C (compartments) 16 бит
Нулевое значение во всех позициях используется когда передача информации не ограничена. Остальные значения для этого поля можно получить от Секретного Оборонного Агенства.
Поле H (введение ограничений) 16 бит
Значения для управления и внесения меток являются буквенно-цифровыми диаграммами и определены в документе DIAM 65-19 «Standard Security Markings».
Поле TCC (поле управления переносом) 24 бита
Дает средства для отслеживания процесса отделения, его значения контролируются группами заинтересованных подписчиков. Значения TCC имеют три поля для записей и могут быть получены из документа HQ DCA Code 530.
Рассматриваемый тип должен копироваться при фрагментации. Эта опция появляется в датаграмме не более одного раза.
Тип 131 Loose Source and Record Route
(Потеря отправителя и запись маршрута)
+———+———+———+——- // ——+
|10000011| длина |указатель|данные о маршруте|
+———+———+———+——- // ——+
Опция потери отправителя и записи маршрута (LSRR) обеспечивает средства, позволяющие отправителю Internet датаграммы передавать информацию, используемую шлюзами при передаче датаграмм по назначению, а также записывать информацию о маршруте. Опция начинается с кода типа. Второй октет — октет длины, которая учитывает код типа опции и сам себя, а также октет указателя. Третий октет является указателем на данные о маршруте, он определяет октет, с которого начинается следующий адрес отправителя, подлежащий обработке. Указатель отсчитывается от начала рассматриваемой опции, а его наименьшее допустимое значение — 4. Данные о маршруте состоят из ряда Internet адресов. Каждый Internet адрес — это 32 бита или 4 октета. Если указатель превышает длину, то маршрут отправителя пуст (поле с записями маршрута заполнено), а маршрутизация должна основываться на значениях поля с адресом получателя. Если адрес, записанный в поле адреса получателя, был достигнут, а указатель не превысил длину, то следующий адрес в маршруте отправителя замещает адрес в поле с адресом получателя. Записанный адрес маршрута заменяет только что использованный адрес отправителя, а указатель увеличивается на 4. Записанный адрес маршрута является собственным Internet адресом Internet модуля, известным во внешнем окружении, куда эта датаграмма направляется. Эта процедура замещения исходного маршрута записанным маршрутом (хотя при обратном порядке он должен использоваться как маршрут отправителя) означает, что данная опция (а также и весь IP заголовок) сохраняет постоянный размер при прохождении датаграммы по Internet системе. Эта опция называется потерей маршрута отправителя (loose source route), поскольку шлюз или IP хост могут использовать любые маршруты через любое количество других промежуточных шлюзов для достижения следующего адреса в рассматриваемом маршруте. При фрагментации опция должна копироваться. В датаграмме она должна появляться не более одного раза.
Тип 137 Strict Source and Record Route
(Уточнить отправитель и записать маршрут)
+———+———+———+——- // ———+
|10001001| длина |указатель| данные о маршруте |
+———+———+———+——- // ———+
Опция «уточнить отправитель и записать маршрут» (SSRR) дает средства отправителю Internet датаграммы для поддержания информации о маршрутизации, которая должна использоваться шлюзами при передаче датаграммы по назначению, а также для записи этой информации.
Опция начинается с кода типа. Второй октет — длина опции, которая учитывает код типа опции и октет длины, октет указателя (3 октета с данными о маршруте). Третий октет является указателем на данные маршрута, определяющим октет, с которого начинается следующий адрес отправителя, подлежащий обработке. Указатель отсчитывается с начала этой опции, а наименьшее допустимое значение указателя — 4.
Данные о маршруте состоят из серии Internet адресов. Каждый Internet адрес — это 32 бита или 4 октета. Если указатель превышает длину, то маршрут отправителя пуст (записываемый маршрут полон), а маршрутизация основывается на значении поля с адресом получателя.
Если адрес в поле адреса получателя был достигнут, а указатель не превышает длины, то следующий адрес в маршруте отправителя замещает адрес в поле с адресом получателя, а записанный адрес маршрута замещает только что использованный адоес отправителя, указатель увеличивается на 4.
Записанный адрес маршрута — это собственный Internet — адрес Internet — модуля, как он был бы распознан во внешней среде, куда эта датаграмма направляется.
Эта процедура замещения маршрута отправителя записанным маршрутом (хотя в обратном порядке он должен использоваться как маршрут отправителя) означает, что опция (и весь IP заголовок) сохраняет постоянный размер при прохождении датаграммы через Internet систему.
Эта опция является точным маршрутом отправителя, поскольку шлюз или IP хост должен посылать данную датаграмму непосредственно на следующий адрес в маршруте отправителя через напрямую соединенную сеть, на адрес, показывающий следующий шлюз или хост, указанный в маршруте.
Опция должна копироваться при фрагментации. Появляется не более одного раза в датаграмме.
Тип 7 Record Route (Записать маршрут)
+———+———+———+——- // ———+
|00000111| длина |указатель| данные о маршруте |
+———+———+———+——- // ———+
Опция записи маршрута дает средства для записи маршрута Internet датаграммы.
Опция начинается с кода типа. Второй октет определяет длину опции, которая учитывает код типа опции, сам себя, октет указателя и длину трех октетов с данными о маршруте. Третий октет является указателем на данные маршрута. Указатель определяет октет, с которого начинается следующее поле для размещения адреса маршрута. Указатель отсчитывается от начала рассматриваемой опции, а его наименьшее допустимое значение — 4.
Записываемый маршрут состоит из серии Internet адресов. Каждый Internet адрес — это 32 бита или 4 октета. Если указатель больше, чем длина опции, то поле с записываемым маршрутом заполнено. Хост — компьютер, создающий эту опцию, должен зарезервировать поле с данными о маршруте и достаточным размером, с тем, чтобы оно вместило все ожидаемые адреса. Размер этой опции не изменяется при добавлении адресов. Первоначальное содержимое поля под данные о маршруте должно быть нулевым.
Когда Internet модуль направляет датаграмму, он проверяет ее на присутствие рассматриваемой опции с записываемым маршрутом. Если она присутствует, то он вставляет свой собственный Internet адрес в качестве распознанного во внешней среде, куда эта датаграмма направлена. Вставка осуществляется в опцию записи маршрута, в то место, на которое указывает октет указателя. Указатель затем увеличивается на 4.
Если поле с данными о маршруте уже заполнено (указатель превышает длину), то датаграмма направляется без вставки адреса в опцию заполняемого маршрута. Если имеется некоторое пространство, но недостаточное для вставки полного адреса, то исходная датаграмма считается ошибочной и разрушается. И в том, и в другом случае на хост-отправитель напрвляется сообщение о проблеме с ICMP параметром [3].
При фрагментации не копируется, присутствует лишь в первом фрагменте. В датаграмме присутствует не более одного раза.
Тип 136 (длина 4) Stream Identifier (Идентификатор потока)
+———+———+———————+
|10001000|00000010|идентификатор потока|
+———+———+———————+
Эта опция дает средства для поддержания 16-битовой SATNET идентифткации потока в сетях, которые парвоначально не поддерживали потоковую концепцию.
Опцтя должна копироваться при фрагментации. В датаграмме появляется не более одного раза.
Тип 68 Internet timestamp (Временной штамп Internet)
+———+———+———+——+——+
|01000100| длина |указатель|oflw | flg |
+———+———+———+——+——+
| Internet адрес |
+—————————————+
| Timestamp |
+—————————————+
| |
Длина — это количество октетов в опции, которое учитывает октеты типа, длины, указателя и overflow/flag (максимальная длина 40 октетов).
Указатель — это количество октетов от начала этой опции до конца временных штампов, плюс единица (т.е. он указывает на октет, с которого начинается свободное место для следующего временного штампа). Наименьшее допустимое значение — 5. Поле временного штампа считается заполненным, когда указатель превышает длину опции.
Overflow (oflw, переполнение 4 бита) — это количество IP модулей, которые не могут произвести регистрацию временных штампов по причине отсутствия свободного места.
Flag (flg, флаги 4 бита) — это 0 — оставлять лишь временные штампы, размещенные в следующих друг за другом 32-битных словах 1 — каждому временному штампу предшествует Internet адрес регистрируемого объекта 3 — поля Internet адресов определены заранее. IP модуль лишь регистрирует свой временной штамп, если его собственный адрес совпадает со следующим указанным Inernet адресом. Timestamp — это выровненный по правой границе 32-битный временной штамп в миллисекундах (относительно полуночи по Единому Времени). Если время в миллисекундах неопределимо или не может быть отсчитано относительно полуночи по Единому Времени, то может быть внесено любое другое время в качестве временного штампа при условии, что самый старший бит в поле временного штампа будет установлен в единицу (что указавает на использование нестандартного значения).
Хост-отправитель должен создавать эту опцию так, чтобы поля для временных штампов были достаточны для размещения всей ожидаемой информации. Размер опции не изменяется при добавлении временных штампов. Первоначально содержимое поля под временные штампы должно быть заполнено нулями, либо Internet адреса должны чередоваться с нулями.
Если поле с временными штампами уже заполнено (указатель превышает длину опции), то датаграмма передается без вставки временного штампа, а счетчик переполнения увеличивается на единицу.
Если имеется место, но оно недостаточно для вставки полного временного штампа, или же счетчик переполнения сам переполнен, то исходная датаграмма рассматривается как ошибочная и уничтожается. И в том, и в другом случае на хост-отправитель должно посылаться сообщение о проблеме с ICMP параметром [3].
Опция временного штампа не копируется при фрагментации, а сохраняется в первом фрагменте. В датаграмме появляется не более одного раза.
Padding (Выравнивание) Выравнивание Internet заголовка используется для того, чтобы убедиться в том, Internet заголовок заканчивается на 32-битной границе. Варавнивание осуществляется нулями.
3.2 Обсуждение
Реализация протокола должна быть ясной. Каждая реализация должна предвидеть работу с другими реализациями, созданными другими людьми. Хотя цель этой спецификации — уточнение данного протокола, тем не менее существует различие интерпретаций. В общем случае реализация должна сохранять консерватизм в манере отправления, а свобода существует лишь в манере получения информации. А именно, реализация должна быть аккуратной в посылке хорошо определенных датаграмм и должна принимать любую датаграмму, которую она могла бы интерпретировать (т.е. нет среды для технических ошибок).
Основные Internet службы ориентированы на датаграммы и обеспечивают фрагментацию датаграмм на шлюзах, сборку на модуле Internet протокола на хосте-получателе. Конечно, фрагментация и сборка датаграмм в сети или по предварительному согласованию между шлюзами также разрешена, поскольку это очевидно для Internet протоколов и протоколов более высокого уровня. Этот очевидный тип фрагментации и сборки называется фрагментацией, зависящей от сети (или Internet), и далее здесь не обсуждается.
Отправителей и получателей на уровне хост-компьютера позволяют отличать Internet адреса, а также поле протокола. Предполагается, что каждый протокол будет определять, есть ли нужда в мультиплексировании на хосте.
Адресация
Чтобы обеспечить гибкость в присвоении адресов комптьютерным сетям и позволить применение большого количества малых и средних сетей, поле адреса кодируется таким образом, чтобы определять малое количество сетей с большим количеством хостов, среднее количество сетей со средним количеством хостов и большое количество сетей с малым количеством хостов. Дополнительно имеется escape код для расширенного режима адресации.
Форматы адресации
Старшие биты Формат Класс
0 7 бит в сети, 24 бита для хостов А
10 14 бит в сети, 16 бит для хостов В
110 21 бит для сети, 8 бит для хостов С
111 переход в расширенный режим адресации
Нулевое значение в поле сети означает данную сеть. Этот режим используется только в определенных ICMP сообщениях. Расширенный режим адресации неопределен. Обе эти возможности зарезервированы для будущих реализаций. Реальные значения, присваиваемые сетевым адресам, даны в документе «Assigned Numbers» [9].
Локальный адрес, присвоенный локальной сети, должен позволять одиночному физическому хосту работать как несколько отдельных Internet хостов. А именно, должен существовать промежуток между адресами Internet хостов и должны присутствовать интерфейсы между сетью и хостом, которые позволили бы нескольким Internet адресам соответствовать одному интерфейсу. Хост должен иметь возможность для поддержки нескольких физических интерфейсов и для обработки датаграмм с любого из них, как если бы они были адресованы к единственному хосту.
Карта соответствия между Internet адресами и адресами таких сетей, как ARPANET, SATNET, PRNET и др. описаны в документе «Address Mapping» [5].
Фрагментация и сборка
Поле Internet идентификации (ID) используется вместе с адресамиотправителя и получателя, полями протокола для идентификации фрагментов датаграммы при сборке.
Бит флага More Fragments (MF) устанавливается, если датаграмма не является последним фрагментом. Поле Fragment Offset идентифицирует расположение фрагмента относительно начала в первоначальной нефрагментированной датаграмме. Единица измерения — 8 октетов. Стратегия фрагментации разработана так, чтобы нефрагментированная датаграмма имела нули во всех полях с информацией о фрагментации (MF=0, Fragment Offset=0). Если же Internet датаграмма фрагментируется, то выделение информации производится кусками и по границе 8 октет.
Данный формат позволяет использовать 2**32=8192 фрагментов по 8 октетов каждый, а в целом 65536 октетов. Заметим, что это совпадает со значением поля общей длины для датаграммы (конечно, заголовок учитывается в общей длине датаграммы, но не фрагментов).
Когда происходит фрагментация, то некоторые опции копируются, а другие остаются лишь в первом фрагменте.
Каждый Internet модуль должен быть способен передать датаграмму из 68 октетов без дальнейшей фрагментации. Это происходит потому, что Internet заголовок может включать до 60 октетов, а минимальный фрагмент — 8 октетов. Каждый Internet — получатель должен быть в состоянии принять датаграмму из 576 октетов в качестве единого куска, либо в виде фрагментов, подлежащих сборке.
Процесс фрагментации может повлиять на предыдущие поля
(1) — поле опций
(2) — флаг «more fragments»
(3) — смещение фрагмента
(4) — поле длины Internet заголовка
(5) — поле общей длины
(6) — контрольная сумма заголовка
Если бит флага запрета фрагментации (Don’t Fragment — DF) установлен, то Internet фрагментация данной датаграммы запрещена, даже если она может быть разрушена. Данное средство может использоваться для предотвращения фрагментации в тех случаях, когда хост-получатель не имеет достаточных ресурсов для сборки Internet фрагментов.
Одним из примеров использования средства запрета фрагментации должна
служить линия, ведущая к малому хосту. Маленький хост может иметь
фмксированную загрузочную программу, которая принимает датаграмму,
помещает в памяти, а затем исполныет ее.
Процедуры фрагментации и сборки наиболее просто описываются примерами. Следующие процедуры являются учебными реализациями.
В следующих псевдопрограммах принимается следующая нотация: «=<» означает «меньше или равно», «#» означает «не равно», «=» означает «равно», «<-» означает «устанавливается в». Кроме этого, «с x по y» означает включительно по x, но не включая y. К примеру, выражение «с 4 по 7» означало бы включение 4,5 и 6, но не включало бы 7.
Пример процедуры фрагментации
Датаграмма наибольшего размера, которая еще может быть передана через очередную локальную сеть, называется наибольшей передаваемой единицей (maximum transmission unit — MTU).
Если общая длина датаграммы меньше или равна максимальной передаваемой единице, то датаграмма передается следующим процедурам обработки. В противном случае прежде она разбивается на два фрагмента, причем первый из них будет иметь максимальный размер, соотвественно во второй фрагмент будет помещен остаток исходной датаграммы. Первый фрагмент отправляется на дальнейшую обработку, а второй повторно подвергается только что рассмотренной процедуре, если и его размер окажется слишком большим.
Обозначения:
FO — смещение фрагмента
IHL — длина Internet заголовка
DF — флаг запрета фрагментации
MF — флаг появления дополнительных фрагментов
TL — общая длина
OFO — старое смещение фрагмента
OIHL — старая длина Internet заголовка
OMF — старое значение флага появление дополнительных фрагментов
OTL — старое значение общей длины
NFB — количество блоков фрагментации
MTU — максимальная длина переноса
Процедура
IF TL =< MTU THEN отправить датаграмму на следующие процедуры
обработки
ELSE
IF DF =1 THEN разрушить датаграмму
ELSE
создать первый фрагмент
(1) скопировать исходный Internet заголовок;
(2) OIHL <- IHL; OTL <- TL; OMF <- MF;
(3) NFB <- (MTU — IHL*4)/8;
(4) взять первые NFB*8 октетов данных;
(5) скорректировать заголовок:
MF <- 1; TL <- (IHL*4)+(NFB*8);
пересчитать контрольную сумму;
(6) направить данный фрагмент на последующие
процедуры обработки
создать второй фрагмент:
(7) выборочно скопировать Internet заголовок (некоторые
опции не копируются, см. определение опций)
(8) добавить оставшиеся данные
(9) скорректировать заголовок
IHL <- (((OIHL*4)-(длина нескопированных опций))+3)/4;
TL <- OTL — NFB*8 — (OIHL-IHL)*4;
FO <- OFO + NFB; MF <- OMF;
пересчитать контрольную сумму;
(10) Приготовить этот фрагмент к повторному тесту на
необходимость фрагментации. Выполнить.
В предыдущей процедуре каждый фрагмент (за исключением последнего) получает максимально разрешенную длину. Альтернатива может заключаться в создании датаграмм, не достигающих максимального размера. Для примера, она может включать процедуру фрагментации, которая повторно делит большие датаграммы пополам до тех пор, пока получающиеся фрагменты не станут короче, чем максимальный допустимый размер передаваемой единицы.
Пример процедуры сборки
Для каждой датаграммы идентификатор буфера определяется как объединение полей адреса отправителя, адреса получателя, протокола и идентификации. Если это целая датаграмма (поля fragment offset и more fragments нулевые), то все ресурсы, связанные с этим идентификатором буфера, освобождаются, а сама датаграмма направляется на следующие процедуры обработки.
Если следующий фрагмент не связан с этим идентификатором буфера, то выделяются ресурсы для сборки. Они включают буфер данных, буфер заголовка, битовую таблицу фрагментации, поле общей длины данных, а также таймер. Данные из фрагмента помещаются в буфер данных в соответствии со значением полей fragment offset и длины, а также устанавливаются биты в битовой таблице фрагментации согласно полученным блокам фрагментов.
Если это первый фрагмент (поле fragment offset нулевое), то его заголовок помещается в буфер заголовка. Если это последний фрагмент (поле more fragments нулевое), то вычисляется общая длина данных. Если этот фрагмент завершает датаграмму (проверяется по установке битов в таблице фрагментации), то датаграмма направляется на следующий этап обработки. В противном случае таймер устанавливается на максимальное из двух: текущее значение таймера и время жизни для данного фрагмента. Выполнение процедуры сборки приостанавливается.
Если таймер отсчитал положенное время, то все ресурсы сборки, связанные с данным идентификатором буфера, освобождаются. Первоначальная установка таймера является нижней границей для времени ожидания при сборке. Это происходит потому, что всемя ожидания будет увеличено, если время жизни приходящего фрагмента окажется больше, но не может быть уменьшено. Установка таймера может достигать максимального времени жизни (примерно 4.25 минуты). В настоящее время рекомендуется первоначально устанавливать таймер на 15 секунд. Это значение можно изменить при получении достаночного практического опыта. Заметим, что выбор значения для этого параметра связи связан с емкостью буфера и скоростью получения данных с коммуникационных сетей. Например, скорость получения данных следует умножать на размер буфера (т.е. 10 кбайт/сек * 15 сек = 150 кбайт).
Обозначения
FO — смещение фрагмента
IHL — длина Internet заголовка
MF — флаг More Fragments
TTL — время жизни
NFB — количество фрагментов
TL — общая длина
TDL — общая длина данных
BUFID — идентификатор буфера
RCVBT — битовая таблица фрагментации
TLB — нижняя граница для значения таймера
Процедура
(1) BUFID <- отправитель|получатель|протокол|идентификация;
(2) IF FO = 0 AND MF = 0 THEN
(3) IF буфер с идентификатором BUFID выделены THEN
(4) Завершить сборку для этого идентификатора BUFID;
(5) Приготовить датаграмму для дальнейшей обработки. Запустить обработку
(6) ELSE IF буфер для идентификатора BUFID не выделен THEN
(7) Выделить ресурсы для сборки с идентификатором BUFID TIMER <- TLB; TDL <- 0;
(8) Перенести данные из фрагмента в буфер данных с идентификатором BUFID, данные с октета FO*8 по октет (TL-(IHL*4))+FO*8;
(9) Установить биты RCVBT с FO по FO+((TL-(IHL*4)+7)/8);
(10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11) IF FO = 0 THEN поместить заголовок в буфер заголовка
(12) IF TDL # 0 AND все биты RCVBT с 0 по (TDL+7)/8 выставлены THEN
(14) TL <- TDL+(IHL*4)
(15) Приготовить датаграмму к дальнейшей обработке
(16) Освободить все ресурсы сборки для этого идентификатора BUFID. Запустить обработку.
(17) TIMER <- MAX(TIMER,TTL);
(18) Приостановить работу до получения следующего фрагмента или сигнала от таймера
(19) Сигнал от таймера:
Освободить все ресурсы, связанные с этим идентификатором BUFID.
В случае, если два или более фрагмента содержат одни и те же данные, либо идентичны или частично перекрываются, то эта процедура будет использовать последнюю полученную копию при создании буфера данных и воссоздании датаграммы.
Идентификация
Выбор способа идентификации исходит из необходимости уникальной идентификации фрагментов конкретной датаграммы. Модуль протокола, собирающий фрагменты, считает, что они относятся к одной и той же датаграмме, если они имеют общего отправителя, получателя, протокол и идентификатор. Таким образом, отправитель должен выбрать идентификатор таким образом, чтобы он был уникален для данной пары отправителя — получателя, для данного протокола и в течении того времени, пока данная датаграмма (или любой ее фрагмент) может существовать в сети Internet.
Очевидно, что модуль протокола, отправляющий датаграммы, должен иметь таблицу идентификаторов, где каждая запись соотносится с каждым отдельным получателем, с которым осуществлялась связь, и указывает последнее значение максимального времени жизни датаграммы в сети Internet.
Однако, поскольку поле идентификатора позволяет использовать 65536 различных значений, некоторые хост-компьютеры могут использовать просто уникальные идентификаторы независимо от адреса получателя.
Обычно идентификаторы выбирают протоколы более высокого уровня, например модули TCP протокола могут повторно передавать идентичные TCP сегменты. Вероятность правильного приема увеличивалась бы, если повторная передача осуществлялась с тем же самым идентификатором, что и исходная датаграмма, поскольку ее фрагменты могли бы использоваться для сборки правильного TCP сегмента.
Тип обслуживания
Тип обслуживания (TOS) используется для выбора качества Internet сервиса. Тип обслуживания определяется абстрактными параметрами приоритета, задержки, продолжительности и достоверности. Эти параметры должны отображаться на реальные параметры сервиса для конкретных сетей, через которые проходит данная датаграмма.
Приоритет. Независимая единица измерения для важности данной датаграммы.
Задержка. Указание задержки важно для датаграмм с этим знаком.
Пропускная способность. Для датаграмм с этим знаком важна высокая скорость передачи данных.
Достоверность. Для датаграмм с таким типом обслуживания важен более высокий уровень усилий, предпринимаемых для обеспечения достоверности.
Например, сеть ARPANET имеет бит приоритета, а также выбор между «стандартными» сообщениями (тип 0) и «неконтролируемыми» (тип 3) (также в качестве одного из сервисных параметров может использоваться выбор между единичным пакетом и многопакетными сообщениями). Неконтролируемые сообщения имеют тенденцию иметь меньшую достоверность, но и меньшую задержку. Допустим, Internet датаграмма должна быть передана через сеть ARPANET. Пусть тип Internet сервиса определен как
приоритет: 5
задержка: 0
пропускная способность: 1
достоверность: 1
В рассматриваемом примере отображение описанных параметров на параметры, допустимые в сети ARPANET, привело бы к установке бита приоритета ARPANET (поскольку приоритет Internet находится в верхней половине своего диапазона), выбору стандартного типа сообщений (поскольку указаны требования высокой пропускной способности и достоверности, а параметр задержки сброшен). Дополнительные детали реализации сервиса даны в документе «Service Mappings» [8].
Время жизни
Время жизни устанавливается отправителем в соответствии с максимальным значением, которое данная датаграмма может иметь в системе Internet. Если датаграмма пребывает в системе Internet дольше, чем указанное время жизни, она подлежит уничтожению.
Значение в поле, где указано время жизни, должно уменьшаться в каждой точке, где обрабатывается Internet заголовок, с тем, чтобы показать время, потраченное на обработку датаграммы. Даже если нет возможности получать информацию о том, сколько реально времени было потрачено, значение этого поля должно быть уменьшено на единицу. Время изменяется в секундах (т.е. указанная единица соответствует одной секунде). Таким образом, максимальное время жизни составляет 255 секунд или 4.25 минуты. Поскольку каждый модуль, обрабатывающий датаграмму, должен уменьшать значение поля TTL по крайней мере на единицу, даже если он обрабатывает ее быстрее, чем за секунду, то поле TTL следует рассматривать лишь как верхнюю границу для времени существования датаграммы. Цель процедуры заключается в разрушении датаграмм, не достигших получателя, а также в ограничении времени жизни датаграммы в сети.
Некоторые протоколы более высокого уровня, управляющие соединениями, основываются на предположении, что старые датаграммы-дубликаты не достигают цели по истечении определенного времени. TTL — это способ, с помощью которого такие протоколы могли бы убедиться, что их предположение удовлетворяется.
Опции
Опции могут присутствовать в любой датаграмме, но должны всегда быть обработаны. А именно, наличие или отсутствие какой-либо опции дело отправителя, но каждый Internet модуль должен быть в состоянии произвести разбор каждой опции.
Опции могут оканчиваться не на 32-битной границе. В этом случае Interntet заголовок может дополняться нулевыми октетами. Первый из них должен интрепретироваться как заключительная опция, а остальные — как октеты выравнивания Internet заголовка по границе.
Каждый Internet модуль должен быть в состоянии реагировать на каждую опцию. Например, опция безопасности требует классификации, внесения ограничений, или передачи по изолированному пути.
Контрольная сумма
Пересчет контрольной суммы Internet заголовка осуществляется каждый раз при его изменении. Например, это происходит при уменьшении времени жизни, добавлении или изменении Internet опций или при фрагментации. Контрольная сумма на уровне Internet имеет целью защиту полей Internet заголовка от ошибок при пересылке.
Существуют некоторые приложения, которые могли бы допустить несколько ошибочных битов в поле данных при условии отсутствия задержки. Однако, если Internet протокол усиливает ошибочность данных, то такие приложения не могут поддерживаться.
Ошибки
Ошибки Internet заголовка могут быть оглашены посредством ICMP сообщений [3].
3.3 Интерфейсы
Функциональное описание взаимодействия между пользователем и Internet протоколом будет, в лучшем случае, умозрительным в силу специфики операционной системы. Следовательно, мы должны предупредить читатетлей, что различные реализации Internet протокола будут иметь различный интерфейс с пользователем. Тем не менее, все реализации должны давать определенный минимальный набор услуг, с тем, чтобы гарантировать , что все они придерживаются единой иерархи протоколов. Данная глава описывает интерфейс с функцией, обызательный для всех реализаций.
Internet протокол взаимодействует, с одной стороны, с локальной сетью, а с другой — с протоколом более высокого уровня или прикладной программой. В дальнейшем протокол более высокого уровня или прикладную программу (или даже программу межсетевого шлюза) мы будем называть «пользователем», поскольку они используют Internet модуль для своих целей. Поскольку Internet протокол — это протокол работы с датаграммами, то в промежутке между этапами их передачи системе придаются минимальные ресурсы памяти, она поддерживает определенные регистры состояния, а следовательно, каждый вызов пользователем Internet протокола сообщает системе всю информацию, необходимую для осуществления требуемого сервиса.
Пример интерфейса с вышестоящим уровнем
Два примера вызовов, приведенные ниже, удовлетворяют запросы пользователя в общении с Internet протоколом (символ «=>» означает возвращаемое значение).
SEND(src,dst,prot,TOS,TTL,BufPTR,len,Id,DF,opt => result)
где
src — адрес отправителя
dst — адрес получателя
prot — протокол
TOS — тип сервиса
TTL — время жизни
BufPTR — указатель буфера
len — длина данных в буфере
Id — идентификатор
DF — запрет фрагментации
opt — опции
result — ответ:
Ok — успешная посылка датаграммы
Error — ошибка в аргументах функции или в локальной сети
Заметим, что тип сервиса TOS включает приоритет, а требование
безопасности передается в качестве опции.
RECV(BufPTR,prot => result,src,dst,TOS,len,opt)
BufPTR — указатель буфера
prot — протокол
result — ответ:
Ok — успешное получение датаграммы
Error — ошибка в аргументах
len — длина буфера
src — адрес отправителя
dst — адрес получателя
TOS — тип сервиса
opt — опции
Когда пользователь отправляет датаграмму, он осуществляет SEND вызов, сопровождаемый всеми аргументами. Модуль Internet протокола по получении этого вызова проверяет аргументы, приготавливает и отправляет сообщение. Если аргументы в порядке, а датаграмма принята локальной сетью, то вызов завершается успешно. Если же агрументы неверны или датаграмма не принята локальной сетью, то вызов завершается с ошибкой. В последнем случае должен быть сделан соответствующий отчет о причине проблемы, однако детали таких отчетов относятся уже к конкретным реализациям.
В момент, когда датаграмма приходит на модуль Internet протокола из локальной сети, может присутствовать ожидающий ее RECV вызов от пользователя — адресата, а может и не присутствовать. В первом случае ожидающий вызов удовлетворяется посылкой информации из датаграммы к пользователю. Во втором случае пользователю — адресату посылается напоминание о ждущей его датаграмме. Если пользователь — адресат не присутствует, отправителю возвращается ICMP сообщение об ошибке, а принятые данные разрушаются.
Напоминание пользователю может быть выполнено через псевдопрерывание или с помощью аналогичного механизма в соответствии с конкретной операционной системой, поддерживающей данную реализацию.
Сделанный пользователем запрос RECV может быть немедленно удовлетворен ждущей этого датаграммой или же он может быть задержан до получения соответствующей датаграммы.
Адрес отправителя включается в запрос на посылку, если отправляющий датаграмму хост-компьютер имеет несколько адресов (несколько физических соединений или же чисто логических адресов). Internet модуль должен следить за тем, чтобы адрес отправителоя был одним из разрешенных адресов для данного хоста.
Реализация протокола может допускать или даже требовать применения запроса к Internet модулю для обозначения заинтересованности, или же, наоборот, использование исключительно какого-либо класса датаграмм (т.е. всех датаграмм, которые имеют в поле протокола определенное занчение).
Данная глава характеризует функции интерфейса между пользователем и Internet протоколом. Используемые обозначения аналогичны большинству процедур функций вызовов на языках высокого уровня, однако данный способ обращения с Internert протоколом не является правилом для запросов на обслуживание типа ловушек (т.е. SVC, UUO, EMT), или для любой другой формы общения между процессами.
Приложение А: Примеры и сценарии
Пример 1
Пример минимальной Internet датаграммы, несущей данные
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Пример Internet датаграммы
Напомним, что каждая метка означает место для одного бита. Здесь приведена Internet датаграмма версии 4 Internet протокола. Internet заголовок состоит из пяти 32 битных слов, а общая длина датаграммы составляет 21 октет. Данная датаграмма является полноценной датаграммой (а не фрагментом).
Пример 2
В данном примере мы показываем сперва Internet датаграмму промежуточного размера (452 октета данных), а затем два Internet фрагмента, которые могли бы возникнуть при фрагментации исходной датаграммы в случае, когда максимальная допустимая единица пересылки составляла 280 октетов.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Пример Internet датаграммы
Теперь приведем первый фрагмент, который возникает при расщеплении исходной датаграммы по границе после 256 октета данных.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Пример Internet фрагмента
и второй фрагмент
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Пример Internet заголовка
Пример 3
Здесь мы показываем пример, когда датаграмма имеет опции
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=8 |Type of Service| Total Length = 576 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Пример Internet датаграммы
Приложение Б: Порядок передачи данных
Порядок передачи заголовка и данных, описанных в данном документе, определяется на уровне октетов. В то время как диаграмма обозначает группу октетов, порядок их передачи является таким же, как при чтении на английском языке. Например, в нижеприведенной диаграмме октеты передаются в порядке номеров.
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 Порядок передачи байтов
Октет представляет собой число, для котрого самый левый бит на диаграмме является самым старшим или самым значащим битом. Так бит, отмеченный нулем, является наиболее значащим битом. Например, следующая диаграмма представляет число 170 (десятичное)
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Рис. 11 Старшинство битов
Аналогично, если многооктетное поле представляет число, то самый левый бит в этом поле является самым значащим битом. При передаче многооктетного чила самый значащий октет передается первым.
Толковый словарь
1822 BBN доклад 1822, «The Specification of the Interconnection of a Host and an IMP». Спецификация взаимодействия между хост-компьютером и сетью ARPANET.
ARPANET проводник Управляющая информация в ARPANET сообщении для интерфейса между хост-компьютером и IMP процессором.
ARPANET сообщение Единица передачи между хост-компьютером и IMP процессором в сети ARPANET. Максимальный ее размер примерно 1012 октетов (8096 битов).
ARPANET пакет Единица передачи внутри сети ARPANET между IMP процессорами. Максимальный размер ее около 126 октетов (1008 бит).
Destination (Получатель) Адрес получателя, поле в Internet заголовке.
DF Бит запрета фрагментации в поле флагов.
Flags (Флаги) Поле Internet заголовка, содержащее различные управляющие биты.
Fragment Offset (Смещение фрагмента) Это поле Internet заголовка указывает, к какому месту в Internet датаграмме относится фрагмент.
GGP Gateway to Gateway Protocol — Протокол общения между шлюзами. Данный протокол первоначально использовался шлюзами для управления маршрутизацией и другими функциями шлюзов.
header (заголовок) Управляющая информация в начале сообщения, сегмента, датаграммы, пакета или блока данных.
ICMP Internet Control Message Protocol — Протокол контрольных сообщений Internet. Поддерживаемое Internet модулем, ICMP сообщение передается от шлюзов к хост-компьютерам и между хост-компьютерами, используется для отчетов об ошибках а также для создания предположений о маршрутизации.
Identification (Идентификация) Поле Internet заголовка, содержащее идентифицирующее значение, назначенное отправителем, и служащее для сборки фрагментов какой-либо датаграммы.
IHL The Internet Header Length — Поле Internet заголовка. Представляет собой длину Internet заголовка, измеренную в 32-битных словах.
IMP The Interface Message Processor — Процессор сообщений интерфейса. Пакетный переключатель сети ARPANET.
Internet Address (адрес Internet) Четырехоктетный (32 бита) адрес отправителя или получателя. Состоит из поля сети и поля локального адреса.
Internet фрагмент Порция данных из Internet датаграммы, снабженная Internet заголовком.
Local Address (локальный адрес) Адрес хост-компьютера внутри какой-либо сети. Реальное отображение локального адреса Internet на адреса хост-компьютеров в сети довольно произвольное, что позволяет отображать несколько локальных адресов на один хост-компьютер.
MF Флаг появления дополнительных фрагментов, содержащийся в поле флагов Internet заголовка
module (модуль) Реализация, обычно программная, протокола или других процедур
more-fragments flag (флаг дополнительных фрагментов) Флаг, показывающий, содержит ли данная Internet датаграмма заключительную часть исходной Internet датаграммы. Флаг включен в поле флагов Internet заголовка.
NFB The Number of Fragments Blocks — количество блоков фрагментации с данными в Internet фрагменте. Иными словами, длина поля с данными. Единица измерения — 8 октет.
octet (октет) байт с восемью битами
Options (опции) Поле опций Internet заголовка, может содержать несколько опций. Каждая опция может иметь длину в несколько октет.
Padding (Выравнивание) Поле выравнивания Internet заголовка, используемое для того, чтобы убедиться в том, что данные начинаются по границе 32-битного слова. Выравнивание осуществляется нулями.
Protocol (Протокол) Для данного документа это идентификатор протокола более высокого уровня, поле в Internet заголовке.
Rest (Остаток) Часть Internet адреса, указывающая локальный адрес.
Source (Отправитель) Адрес отправителя, поле Internet заголовка.
TCP Transmission Control Protocol — Протокол управления передачей. Протокол общения между хост-компьютерами для осуществления коммуникаций в среде Internet.
TCP сегмент Единица данных, передаваемая между TCP модулями (имеющая TCP заголовок).
TFTP Trivial File Transfer Protocol: Простой протокол передачи файлов, созданный для UDP.
Time to Live (Время жизни) Поле Internet заголовка, показывающее верхний предел для времени существования данной Internet датаграммы.
TOS Тип сервиса
Total length (общая длина) Поле Internet заголовка Total Length, определяющее длину датаграммы в октетах, включающее Internet заголовок и данные.
TTL Время жизни
Type of Service (Тип сервиса) Поле Internet заголовка, определяющее тип сервиса для данной Internet датаграммы.
UDP User Datagram Protocol. Протокол на уровне пользователя для приложений, ориентированных на транзакции.
User (Пользователь) Пользователь Internet протокола. Это может быть модуль протокола более высокого уровня, прикладная программа или программа шлюза.
Version (версия) Поле версии, определяющее формат Internet заголовка.
Ссылки
[1] Cerf, V., «The Catenet Model for Internetworking,» Офис технологий обработки информации, Оборонное Агентство расширенных исследовательских проектов, IEN 48, июль 1978.
[2] Bolt Beranek and Newman, «Specification for the Interconnection of a Host and an IMP,» BBN Технический отчет 1822, пересмотрен в мае 1978.
[3] Postel, J., «Internet Control Message Protocol — DARPA Internet Program Protocol Specification,» RFC 792, USC/Институт Информатики, сентябрь 1981.
[4] Shoch, J., «Inter-Network Naming, Addressing, and Routing,» COMPCON, компьютерное общество IEEE, конец 1978 года.
[5] Postel, J., «Address Mappings,» RFC 796, USC/Институт Информатики, сентябрь 1981.
[6] Shoch, J., «Packet Fragmentation in Inter-Network Protocols,» Computer Networks, v.3, n.1, январь 1979.
[7] Strazisar, V., «How to Build a Gateway», IEN 109, Bolt Beranek and Newman, август 1979.
[8] Postel, J., «Service Mappings,» RFC 795, USC/Институт Информатики, сентябрь 1981.
[9] Postel, J., «Assigned Numbers,» RFC 790, USC/Институт Информатики, сентябрь 1981.
