RFC 8507 | Спецификация простого интернет-протокола (SIP)

Аннотация

Этот документ опубликован для исторической записи. Простой Интернет-протокол стал основой для одного из кандидатов на работу IETF Next Generation (IPng), которая стала IPv6.

Скачать оригинальный документ на английском языке RFC 8507 PDF

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

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

Этот документ определяет новую версию IP под названием SIP, Простой Интернет-протокол. В нем также описаны изменения, необходимые для ICMP, IGMP и транспортных протоколов, таких как TCP и UDP, для работы с SIP. Сопутствующий документ [SIP-ADDR] описывает аспекты адресации и маршрутизации SIP, включая вопросы автоматической настройки, мобильности хоста и подсети, а также многоадресной рассылки.

 

Оглавление

1. Предисловие
2. Введение
3. Терминология
4. Формат заголовка SIP
5. Адреса
5.1. Текстовое представление адресов
5.2. Адреса одноадресной рассылки
5.3. Адреса многоадресной рассылки
5.4. Специальные адреса
6. Размер пакета
7. Исходный заголовок маршрутизации
8. Фрагментация заголовка
9. Изменения в других протоколах
9.1. Изменения в ICMP
9.2. Изменения в IGMP
9.3. Изменения в транспортных протоколах
9.4. Изменения в протоколах канального уровня
10. Вопросы безопасности
11. Благодарности
12. Информационные ссылки
Приложение А. Обоснование дизайна SIP
Приложение B. Будущие направления
Адреса авторов

 

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

Этот документ не является спецификацией Internet Standards Track; это опубликовано для исторического отчета.

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

Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8507.

 

Уведомление об авторских правах

Copyright (c) 2018 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ППГ 78 и Правовые положения IETF Trust в отношении документов IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа.

 

1. Предисловие

Этот документ опубликован для исторической записи.

Простой IP (SIP) был основой для одного из кандидатов на работу IETF следующего поколения (IPng); см. «Рекомендация по протоколу IP следующего поколения» [RFC1752]. Оригинальный Интернет-проект 1992 года, описывающий SIP, публикуется здесь как часть отчета об этой работе.

SIP превратился в SIP Plus [RFC1710], который был оценен как кандидат на IPng [RFC1752] и привел в конечном итоге к разработке IPv6, впервые опубликованной как [RFC1883]. Текущая спецификация для IPv6 — [RFC8200].

Первоначальный Интернет-проект, описывающий Простой интернет-протокол, был написан Стивом Дирингом, а Интернет-проект был опубликован 10 ноября 1992 года. Содержание этого документа не отличается от этого Интернет-проекта, за исключением пояснений в Резюме, добавление этого раздела, внесение изменений в информацию об авторах, обновление ссылок, удаление соображений IANA и незначительные изменения форматирования.

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

 

2. Введение

SIP — это новая версия IP. Его существенные отличия от версии 4 IP [RFC791], впоследствии именуемой «IPv4»:

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

SIP сохраняет модель IP глобально уникальных адресов, иерархически структурированных для эффективной маршрутизации. Увеличение размера адреса с 32 до 64 бит позволяет закодировать в адресах больше уровней иерархии, что достаточно для эффективной маршрутизации в Интернете с десятками тысяч адресуемых устройств в каждом офисе, каждом доме и каждом транспортном средстве в мире. Сохранение адресов фиксированной длины и относительно компактных упрощает реализацию высокопроизводительного маршрутизатора и хоста и снижает нагрузку на полосу пропускания заголовков SIP почти на уровне IPv4.

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

Несмотря на эти изменения, SIP остается очень похожим на IPv4. Это сходство облегчает понимание SIP (для тех, кто уже понимает IPv4), позволяет повторно использовать большую часть кода и структур данных из IPv4 в реализации SIP (включая почти все ICMP и IGMP) и делает его простым осуществлять трансляцию между пакетами SIP и пакетами IPv4 для целей перехода [IPAE].

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

 

3. Терминология

system (Система) — это устройство, реализующее SIP.

router (Маршрутизатор) — система, которая пересылает SIP-пакеты.

host (Хост) — любая система, которая не является маршрутизатором.

link (Ссылка) — средство связи или среда, по которой системы могут обмениваться данными на канальном уровне, то есть на уровне, находящемся непосредственно под SIP.

interface (Интерфейс) — точка подключения системы к ссылке.

address (Адрес) — идентификатор уровня SIP для интерфейса или группы интерфейсов.

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

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

path MTU (MTU пути) — минимальный MTU канала связи для всех каналов на пути между исходной системой и системой назначения.

packetization layer (Уровень пакетирования) — любой уровень протокола выше SIP, который отвечает за пакетирование данных для соответствия исходящим пакетам SIP. Как правило, протоколы транспортного уровня, такие как TCP, являются протоколами пакетирования, но могут также существовать протоколы пакетирования более высокого уровня, такие как протоколы, реализованные поверх UDP.

4. Формат заголовка SIP

Version — Версия

4-битный номер версии IP = десятичный 6. <будет подтверждено>

Reserved — Зарезервированный

28-битное зарезервированное поле. Инициализируется на ноль для передачи; игнорируется на приеме.

Payload Length — Длина полезной нагрузки

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

Payload Type — Тип полезной нагрузки

8-битный селектор. Определяет тип полезной нагрузки, например, TCP.

Hop Limit — Предел прыжка

8-битное целое число без знака. Уменьшается на 1 каждой системой, которая пересылает пакет. Пакет отбрасывается, если Hop Limit уменьшается до нуля.

Source Address — Адрес источника

64 бита Смотрите раздел «Адреса», следующий.

Destination Address — Адрес назначения

64 бита Смотрите раздел «Адреса», следующий.

 

5. Адреса

5.1. Текстовое представление адресов

SIP-адреса имеют длину 64 бита (8 октетов). Текстовое представление адресов SIP состоит из 16 шестнадцатеричных цифр, двоеточие между 4-й и 5-й цифрами и необязательные двоеточия между любой последующей парой цифр. Ведущие нули нельзя сбрасывать. Примеры:

0123:4567:89AB:CDEF
0123:456789ABCDEF
0123:456789AB:CDE:F

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

Наличие хотя бы одного двоеточия в текстовом представлении позволяет легко отличить адреса SIP как от доменных имен, так и от текстового представления адресов IPv4.

5.2. Адреса одноадресной рассылки

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

Система считает, что ее собственные одноадресные адреса имеют следующую структуру, где разные адреса могут иметь разные значения для n:

Чтобы узнать длину префикса подсети, система должна связать с каждым из своих адресов «маску подсети» следующей формы:

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

Система получает свою маску (-и) подсети одновременно и тем же механизмом, как она получает свой адрес (-ы), например, путем ручной настройки или с помощью протокола динамической конфигурации, такого как BOOTP [RFC951].

Хосты не знают о какой-либо дальнейшей структуре в одноадресном адресе.

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

с помощью которого они могли бы вывести следующую структуру в адресах сайта:

Все знания SIP-систем о структуре адресов одноадресной рассылки основаны на владении такими масками — отсутствует «зашитое» знание форматов адресов одноадресной рассылки.

В документе SIP-адресации и маршрутизации [SIP-ADDR] предлагаются два иерархических плана адресации, один на основе иерархии поставщиков услуг SIP, а другой — на основе географической иерархии.

5.3. Адреса многоадресной рассылки

Многоадресный адрес SIP является идентификатором для группы интерфейсов. Интерфейс может принадлежать к любому количеству групп многоадресной рассылки. Адреса многоадресной рассылки имеют следующий формат:

где:

C = флаг совместимости IPv4; см. [IPAE].

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

flgs — это набор из 4 флагов:

3 старших флага зарезервированы и должны быть установлены в 0.
T = 0 указывает постоянно назначенный («общеизвестный») адрес многоадресной рассылки, назначенный глобальным органом по нумерации в Интернете.
T = 1 указывает не назначенный постоянно («временный») адрес многоадресной рассылки.

scop — это 4-битное значение многоадресной области:

0 reserved
1 intra-system scope
2 intra-link scope
3 (unassigned)
4 (unassigned)
5 intra-site scope
6 (unassigned)
7 (unassigned)
8 intra-metro scope
9 (unassigned)
A (unassigned)
B intra-country scope
C (unassigned)
D (unassigned)
E global scope
F reserved

0 зарезервировано
1 внутрисистемная область
2 интрассылки
3 (без назначения)
4 (без назначения)
5 внутрисайтовый охват
6 (без назначения)
7 (без назначения)
8 внутригородский прицел
9 (без назначения)
A (неназначенный)
B внутри страны
C (неназначенный)
D (без назначения)
E глобальная сфера
F защищены

group ID (идентификатор группы) идентифицирует многоадресную группу, постоянную или временную, в пределах данной области.

«Значение — meaning» постоянно назначенного адреса многоадресной рассылки не зависит от значения области. Например, если «группе серверов NTP» назначен постоянный многоадресный адрес с идентификатором группы 43 (шестнадцатеричное), то:

• 7F01: 000000000043 означает все NTP-серверы в той же системе, что и отправитель.
• 7F02: 000000000043 означает все NTP-серверы в той же ссылке, что и отправитель.
• 7F05: 000000000043 означает все NTP-серверы на том же сайте, что и отправитель.
• 7F0E: 000000000043 означает все NTP-серверы в Интернете.

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

5.4. Специальные адреса

Существует ряд SIP-адресов «специального назначения»:

Неуказанный адрес (Unspecified Address): 0000: 0000: 0000: 0000

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

Адрес обратной связи (Loopback Address): 0000: 0000: 0000: 0001

Этот адрес может использоваться системой для отправки пакета SIP самому себе.

Любой адрес (Anyone Addresses): <prefix><zero>

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

Поскольку хосты знают только свой префикс (-ы) подсети, а не префиксы более высокого уровня, хост со следующим адресом:

признает только следующий адрес Anyone как идентифицирующий себя:

Внутри-сайтовый маршрутизатор, который знает, что один из его адресов имеет формат:

должен принимать пакеты, отправленные на любой из следующих двух адресов Anyone, как если бы они были отправлены на собственный адрес маршрутизатора:

Любые адреса работают следующим образом:

• Если какая-либо система, принадлежащая подсети A, отправляет пакет на адрес Anyone подсети A, пакет должен быть закольцован внутри самой отправляющей системы, поскольку он является ближайшей к себе системой с префиксом подсети A. Если система за пределами подсети A отправляет пакет на адрес Anyone подсети A, пакет должен быть принят первым маршрутизатором в подсети A, к которому пакет пришел.
• Аналогичным образом, пакет, отправленный на адрес Anyone сайта X из-за пределов сайта X, будет принят первым обнаруженным маршрутизатором, принадлежащим сайту X, то есть одному из граничных маршрутизаторов сайта X. Если префикс верхнего уровня P идентифицирует, скажем, конкретного поставщика услуг, то пакет, отправленный на <P> <ноль> извне средств поставщика P, должен быть доставлен на ближайший входной маршрутизатор в средства P.

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

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

Зарезервированный адрес многоадресной рассылки: 7F0s: 0000: 0000: 0000. Этот адрес многоадресной рассылки (с любым значением области) зарезервирован и никогда не должен назначаться какой-либо группе многоадресной рассылки.

Адреса всех систем: 7F01: 0000: 0000: 0001, 7F02: 0000: 0000: 0001. Эти многоадресные адреса идентифицируют группу всех систем SIP в пределах области 1 (внутрисистемная) или 2 (внутриканальная).

Адреса всех хостов: 7F01: 0000: 0000: 0002, 7F02: 0000: 0000: 0002. Эти многоадресные адреса идентифицируют группу всех хостов SIP в пределах области 1 (внутрисистемная) или 2 (внутриканальная).

Адреса всех маршрутизаторов: 7F01: 0000: 0000: 0003, 7F02: 0000: 0000: 0003. Эти многоадресные адреса идентифицируют группу всех SIP-маршрутизаторов в пределах области 1 (внутрисистемная) или 2 (внутриканальная).

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

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

6. Размер пакета

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

(Примечание: этот минимальный MTU канала НЕ является тем же, что и в IPv4. В IPv4 минимальный MTU канала составляет 68 октетов [[RFC791], стр. 25]; 576 октетов — это минимальный размер буфера сборки, требуемый в системе IPv4, который не имеет никакого отношения к ссылочным MTU.)

Из каждой ссылки, к которой система подключена напрямую, система должна иметь возможность принимать пакеты размером до MTU этой линии. Для ссылок с настраиваемым MTU, таких как PPP-ссылки [RFC1661], должен быть настроен MTU с 600 октетами или более.

Ожидается, что в системах SIP будет реализовано обнаружение Path MTU [RFC1191], чтобы обнаруживать и использовать пути с MTU, превышающим 576 октетов. Однако минимальная реализация SIP (например, в загрузочном ПЗУ) может просто ограничиться отправкой пакетов размером не более 576 октетов и исключить реализацию Path MTU Discovery.

MTU Path Discovery требует поддержки как на уровне SIP, так и на уровнях пакетирования. Система, которая поддерживает обнаружение MTU пути на уровне SIP, может обслуживать уровни пакетирования, которые не могут адаптироваться к изменениям MTU пути. Такие уровни пакетирования должны ограничиваться отправкой пакетов длиной не более 576 октетов, даже при отправке в пункты назначения, принадлежащие к одной подсети.

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

7. Исходный заголовок маршрутизации

Тип полезной нагрузки <TBD> в непосредственно предшествующем заголовке указывает на наличие этого заголовка маршрутизации источника:

Reserved (Зарезервировано) Инициализировано в ноль для передачи; игнорируется на приеме.

Num Addrs Количество адресов в заголовке маршрутизации источника.

Next Addr Индекс следующего адреса для обработки; инициализируется до 0 исходной системой.

Payload Type (Тип полезной нагрузки) Определяет тип полезной нагрузки после заголовка маршрутизации источника.

Заголовок маршрутизации источника не проверяется и не обрабатывается до тех пор, пока не достигнет системы, указанной в поле «Адрес назначения» заголовка SIP. В этой системе диспетчеризация типа полезной нагрузки заголовка SIP (или последующего) вызывает модуль маршрутизации источника, который выполняет следующий алгоритм:

• Если Next Addr <Num Addrs, поменяйте местами адрес и адрес SIP [Next Addr], увеличьте значение Next Addr на единицу и повторно отправьте пакет в модуль SIP для пересылки в следующий пункт назначения.
• Если Next Addr = Num Addrs, отправка модулю локального протокола, указанному в поле «Тип полезной нагрузки» в заголовке «Маршрутизация источника».
• Если Next Addr> Num Addrs, отправьте сообщение об ошибке параметра ICMP по адресу источника, указывая на поле Num Addrs.

8. Заголовок фрагментации (Fragmentation Header)

Тип полезной нагрузки <TBD> в непосредственно предшествующем заголовке указывает на наличие этого заголовка фрагментации:

Identification (Удостоверение личности). Значение, которое изменяется для каждого пакета, отправляемого с тем же адресом источника, адресом назначения и предшествующим типом полезной нагрузки.

M flag (М флаг) 1 = больше фрагментов; 0 = последний фрагмент.

Fragment Offset (Смещение фрагмента) Смещение в 8-октетных порциях следующей полезной нагрузки относительно исходной нефрагментированной полезной нагрузки.

Payload Type (Тип полезной нагрузки) Определяет тип полезной нагрузки после заголовка фрагментации.

Reserved (Зарезервировано) Инициализировано в ноль для передачи; игнорируется на приеме.

Заголовок фрагментации НЕ предназначен для поддержки общей фрагментации уровня SIP. В частности, маршрутизаторы SIP не должны фрагментировать пакет SIP, который является слишком большим для MTU его следующего перехода, за исключением особых случаев, описанных ниже; в обычном случае такой пакет приводит к тому, что сообщение ICMP Packet Too Big отправляется обратно его источнику для использования алгоритмом Path MTU Discovery в исходной системе.

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

• Пакет SIP, который «туннелируется» либо путем инкапсуляции в другом пакете SIP, либо путем вставки заголовка маршрутизации источника по маршруту, может после добавления дополнительных полей заголовка превышать MTU пути туннеля; если исходный пакет имеет длину 576 октетов или менее, система входа в туннель не может ответить на источник сообщением Packet Too Big и поэтому должна вставить заголовок фрагментации и фрагментировать пакет, чтобы уместить его в MTU туннеля.
• Фрагмент IPv4, который транслируется в пакет SIP, или нефрагментированный пакет IPv4, который транслируется в слишком длинный пакет SIP, чтобы поместиться в MTU оставшегося пути, должен включать заголовок фрагментации SIP, чтобы его можно было правильно собрать в месте назначения. SIP система.

Каждая система SIP должна поддерживать фрагментацию и повторную сборку SIP, поскольку любая система может быть настроена для использования в качестве точки входа или выхода туннеля, а любая система SIP может быть местом назначения фрагментов IPv4. Все системы SIP должны быть способны собирать из фрагментов пакет SIP длиной до 1024 октетов, включая заголовок SIP; система может быть способна собирать пакеты длиной более 1024 октетов.

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

Фрагментация и повторная сборка используют тот же алгоритм, что и IPv4, со следующими исключениями:

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

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

 

9. Изменения в других протоколах

Обновление IPv4 до SIP влечет за собой изменения в связанных протоколах управления, ICMP и IGMP, а также на транспортном уровне выше и, возможно, на канальном уровне ниже. Этот раздел определяет эти изменения.

9.1. Изменения в ICMP

SIP использует подмножество ICMP [[RFC792], [RFC950], [RFC1122], [RFC1191], [RFC1256]], с небольшими изменениями и некоторыми дополнениями. Наличие заголовка ICMP указывается типом полезной нагрузки 1.

Одно из изменений во всех сообщениях ICMP заключается в том, что при использовании с SIP контрольная сумма ICMP включает псевдозаголовок, такой как TCP и UDP, состоящий из адреса источника SIP, адреса назначения, длины полезной нагрузки и типа полезной нагрузки (см. Раздел 8.3).

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

Для большинства типов сообщений ICMP пакеты сохраняют тот же формат и семантику, что и в IPv4; однако некоторые поля получают новые имена, соответствующие терминологии SIP.

Изменения в определенных типах сообщений следующие:

Destination Unreachable (Пункт назначения недоступен).

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

1 — адрес получателя недоступен (IPv4 «узел недоступен»)
7 — адрес получателя неизвестен (IPv4 «адресат хоста неизвестен»)
2 — тип полезной нагрузки неизвестен (IPv4 «протокол недоступен»)
4 — слишком большой пакет (IPv4 «необходима фрагментация и установлен DF»)

Следующие коды сохраняют одинаковые имена при использовании с SIP:
3 — порт недоступен
5 — исходный маршрут не пройден
8 — исходный узел изолирован
13 — общение в административном порядке запрещено

Следующие коды не используются с SIP:
0 — нет доступа
6 — сеть назначения неизвестна
9 — комм. с дест. сеть административно запрещена
10 — комм. с дест. Хост административно запрещен
11 — сеть недоступна для типа услуги
12 — хост недоступен для типа услуги

Для сообщений «слишком большой пакет» (код 4) минимальное допустимое значение в поле Next-Hop MTU [RFC1191] составляет 576.

Time Exceeded (Превышено время)

Название кода 0 изменено на «превышен лимит пересылки при передаче».

Parameter Problem (Параметр Проблема)

Поле указателя расширено до 16 бит и перемещено в младший конец второго 32-битного слова следующим образом:

Redirect (Переадресация)

Только код 1 используется для SIP, что означает «перенаправить пакеты для адреса назначения».

Заголовок Redirect изменен для SIP, чтобы приспособиться к 64-битному адресу «предпочтительного маршрутизатора» и сохранить 64-битное выравнивание следующим образом:

Router Advertisement (Реклама Маршрутизатора)

Формат рекламного сообщения маршрутизатора изменен на:

Значение в поле Addr Entry Size равно 4, и все поля Reserved инициализируются отправителями на ноль и игнорируются получателями.

Router Solicitation (Домогательства роутера)

Без изменений.

Echo and Echo Reply (Эхо и Эхо Ответ)

Без изменений.

Следующие типы сообщений ICMP не используются с SIP:

• Source Quench (Источник гасит)
• Timestamp (Отметка)
• Timestamp Reply (Ответ на отметку времени)
• Information Request (Запрос информации)
• Information Reply (Информационный ответ)
• Address Mask Request (Запрос маски адреса)
• Address Mask Reply (Адрес Маска Ответить)

9.2. Изменения в IGMP

SIP использует протокол управления группами Интернет, IGMP [RFC1112]. Наличие заголовка IGMP указывается типом полезной нагрузки 2.

При использовании с SIP контрольная сумма IGMP включает псевдо-заголовок, такой как TCP и UDP, состоящий из адреса источника SIP, адреса назначения, длины полезной нагрузки и типа полезной нагрузки (см. Раздел 8.3).

Формат сообщения запроса членства хоста IGMP:

Формат сообщения с отчетом о членстве в хосте IGMP:

Для обоих типов сообщений номер версии остается равным 1, а поля Reserved установлены равными нулю отправителями и игнорируются получателями.

9.3. Изменения в транспортных протоколах

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

• Любые адреса, передаваемые через интерфейс, имеют длину 64 бита, а не 32 бита.
• Следующие переменные IPv4 не передаются через интерфейс: приоритет, тип обслуживания, идентификатор, флаг фрагмента не
• Параметры SIP имеют формат, отличный от параметров IPv4. (Для SIP «параметры» — это все заголовки между заголовком SIP и транспортным заголовком и не включая его. Единственная опция IPv4, в настоящее время указанная для SIP, — это Loose Source Routing.
• Сообщения об ошибках ICMP для SIP, которые передаются на транспортный уровень, содержат первые 256 октетов вызывающего пакета SIP.

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

Для SIP контрольные суммы псевдозаголовка TCP, UDP, ICMP и IGMP включают в себя адрес источника SIP, адрес назначения, длину полезной нагрузки и тип полезной нагрузки со следующими оговорками:

• Если пакет содержит заголовок маршрутизации источника, адрес получателя, используемый в контрольной сумме псевдозаголовка, является адресом конечного получателя.
• Длина полезной нагрузки, используемая в контрольной сумме псевдозаголовка, представляет собой длину пакета транспортного уровня, включая транспортный заголовок.
• Тип полезной нагрузки, используемый в контрольной сумме псевдозаголовка, является типом полезной нагрузки из заголовка, непосредственно предшествующего транспортному заголовку.
• При добавлении к контрольной сумме псевдозаголовка тип полезной нагрузки обрабатывается как левый октет 16-битного слова с нулями в правом октете при просмотре в стандартном порядке октетов IP.
• Если для любого из двух адресов, используемых в контрольной сумме псевдозаголовка, бит старшего разряда установлен в 1, в сумме должны использоваться только младшие 32 бита этого адреса. Бит старшего разряда используется, чтобы указать, что адресуемая система является системой IPv4, и что младшие 32 бита адреса содержат IPv4-адрес этой системы [IPAE].

Семантика службы SIP отличается от службы IPv4 тремя способами, которые могут повлиять на некоторые транспортные протоколы:

• (1) SIP не обеспечивает максимальное время жизни пакета. Любой транспортный протокол, который использует IPv4 для ограничения времени жизни пакета, должен учитывать это изменение, например, предоставляя свои собственные механизмы для обнаружения и отбрасывания устаревших пакетов.
• (2) SIP не проверяет контрольную сумму своих собственных полей заголовка. Любой транспортный протокол, который использует IPv4 для обеспечения целостности адресов источника и назначения, длины пакета и идентификатора транспортного протокола, должен учитывать это изменение. В частности, при использовании с SIP контрольная сумма UDP является обязательной, а ICMP и IGMP изменяются для использования контрольной суммы псевдозаголовка.
• (3) SIP не (кроме особых случаев) не фрагментирует пакеты, которые превышают MTU их путей доставки. Следовательно, транспортный протокол не должен отправлять пакеты длиннее 576 октетов, если он не реализует обнаружение MTU пути [RFC1191] и не способен адаптировать размер передаваемого пакета в ответ на изменения MTU пути.

9.4. Изменения в протоколах канального уровня

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

Для каналов, по которым ARP используется IPv4, для протокола SIP используется идентичный протокол ARP. Младшие 32-битные SIP-адреса используются везде, где будут появляться адреса IPv4; поскольку ARP используется только среди систем в одной подсети, старшие 32-битные адреса SIP могут быть выведены из префикса подсети (при условии, что префикс подсети имеет длину не менее 32 бит). [Это может быть изменено — см. Приложение B.]

 

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

<to be done> <будет сделано>

 

11. Благодарности

Автор признает многие полезные предложения и слова поддержки от Дейва Кларка, Дэйва Крокера, Деборы Эстрин, Боба Хиндена, Кристиана Уитема, Ван Якобсона, Джеффа Могула, Дейва Николса, Эрика Нордмарка, Дэйва Орана, Крейга Партриджа, Скотта Шенкера, Пола Tsuchiya, Lixia Zhang, члены сквозной исследовательской группы и рабочей группы IPAE, а также участники списков рассылки по большому интернету и sip. Он приносит извинения тем, чьи имена он не перечислил явно. [Если вы хотите быть в списке в следующем проекте, просто дайте ему знать!]

Примечание редактора: Стив Диринг работал в исследовательском центре Xerox в Пало-Альто в Пало-Альто, Калифорния, США, когда эта работа была завершена.

12. Информационные ссылки

[IPAE] Crocker, D. and R. Hinden, «IP Address Encapsulation

(IPAE): A Mechanism for Introducing a New IP», Work in Progress, draft-crocker-ip-encaps-01, November 1992.

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC792] Postel, J., «Internet Control Message Protocol», STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.

[RFC950] Mogul, J. and J. Postel, «Internet Standard Subnetting Procedure», STD 5, RFC 950, DOI 10.17487/RFC0950, August 1985, <https://www.rfc-editor.org/info/rfc950>.

[RFC951] Croft, W. and J. Gilmore, «Bootstrap Protocol», RFC 951, DOI 10.17487/RFC0951, September 1985, <https://www.rfc-editor.org/info/rfc951>.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC1256] Deering, S., Ed., «ICMP Router Discovery Messages», RFC 1256, DOI 10.17487/RFC1256, September 1991, <https://www.rfc-editor.org/info/rfc1256>.

[RFC1661] Simpson, W., Ed., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, <https://www.rfc-editor.org/info/rfc1661>.

[RFC1710] Hinden, R., «Simple Internet Protocol Plus White Paper», RFC 1710, DOI 10.17487/RFC1710, October 1994, <https://www.rfc-editor.org/info/rfc1710>.

[RFC1752] Bradner, S. and A. Mankin, «The Recommendation for the IP Next Generation Protocol», RFC 1752, DOI 10.17487/RFC1752, January 1995, <https://www.rfc-editor.org/info/rfc1752>.

[RFC1883] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 1883, DOI 10.17487/RFC1883, December 1995, <https://www.rfc-editor.org/info/rfc1883>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[SIP-ADDR] Deering, S., «Simple Internet Protocol (SIP) Addressing and Routing», Work in Progress, November 1992.

Приложение А. Обоснование дизайна SIP

<этот раздел еще предстоит сделать>

Поля, присутствующие в IPv4, но отсутствующие в SIP:

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

Нужно обосновать:

изменение общей длины -> длина полезной нагрузки, исключая заголовок

изменение протокола -> Тип полезной нагрузки

изменение времени жизни -> Hop Limit

перемещение полей фрагментации из фиксированного заголовка с большим минимальным MTU и опорой на PMTU Discovery

Приложение B. Будущие направления

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

• ARP может быть модифицирован для переноса полных 64-битных адресов и использования групповых адресов канального уровня, а не широковещательных адресов.
• 28-битное зарезервированное поле в заголовке SIP может быть определено как «Идентификатор потока» или разделено на поле «Тип услуги» и поле «Идентификатор потока» для классификации пакетов, заслуживающих особой обработки, например, с нестандартным качеством сервис или сервис в реальном времени. С другой стороны, поля порта транспортного уровня могут быть достаточными для выполнения любой такой классификации. (Одна из возможностей — просто удалить поля портов из TCP и UDP и добавить их в заголовок SIP, как в XNS.)
• Может быть определено новое сообщение ICMP «назначение перемещено» для перенаправления на мобильные хосты или подсети и на домены, которые изменили свои префиксы адресов.
• может быть определено явное сообщение или опция маршрута трассировки; текущая схема трассировки IPv4 будет хорошо работать с SIP, но она не работает для многоадресной рассылки, для которой стало совершенно очевидно, что необходимы инструменты управления и отладки.
• Может быть указан новый протокол Host-to-Router, охватывающий требования обнаружения маршрутизатора, обнаружения черной дыры, автоматической настройки префиксов подсети, «маяка» для мобильных хостов и, возможно, разрешения адресов. Протокол оконечной системы OSI к промежуточной системе может служить хорошей моделью для такого протокола.
• Требование строгой привязки адресов SIP к интерфейсам может быть ослаблено, так что, например, система может иметь меньше адресов, чем интерфейсов. В текущем Интернете есть некоторый опыт использования этого подхода с использованием «ненумерованных ссылок» в протоколах маршрутизации, таких как OSPF.
• Могут быть определены механизмы аутентификации и обеспечения целостности для всех клиентов SIP, включая ICMP и IGMP, возможно, на основе протокола SP-3 или SP-4 Системы защиты данных (SNDS).

Адреса авторов

Stephen E. Deering
Retired
Vancouver, British Columbia
Canada

Robert M. Hinden (editor)
Check Point Software
959 Skyway Road
San Carlos, CA 94070
USA

Email: bob.hinden@gmail.com