Надежная доставка управляющих сообщений
L2TP обеспечивает нижний уровень надежного транспорта для всех управляющих сообщений. Поля Nr и Ns заголовка управляющего сообщения (смотри раздел 3.1) относятся к этому транспорту. Функции верхнего уровня L2TP не занимаются повторной пересылкой или упорядочением управляющих сообщений. Надежный управляющий канал обеспечивается за счет специального протокола, например, TCP, поддерживающего повторную пересылку управляющих сообщений и контроль перегрузки. Каждый партнер поддерживает независимую нумерацию сообщений для управляющего канала в туннеле.
Порядковые номера сообщений Ns начинаются с 0. Каждое последующее сообщение имеет номер на 1 больше, чем предыдущее. Номер по порядку, таким образом, является простым счетчиком, работающим по модулю 65536. Порядковый номер в заголовке полученного сообщения рассматривается меньше или равным последнему полученному числу, если его значение лежит в интервале между последним полученным кодом и предыдущими 32767 включительно. Например, если последний полученный номер был равен 15, тогда сообщения с порядковыми номерами 0 - 15, а также 32784 - 65535, будут рассматриваться как сообщение с меньшим или равным номером. Такое сообщение будет рассматриваться как дубликат уже полученного и не будет обрабатываться. Однако, для того чтобы гарантировать, что все сообщения подтверждены корректно (в частности в случае потери сообщения ZLB ACK), получение сообщения-дубликата должно быть подтверждено. Это подтверждение может быть реализовано косвенно, или непосредственно через ZLB ACK.
Все управляющие сообщения в пространстве номеров занимают одну нишу, за исключением подтверждения ZLB. Таким образом, Ns не инкрементируется после посылки сообщения ZLB.
Номер последнего полученного сообщения, Nr, используется для подтверждения сообщений, принятых L2TP-партнером. Этот код должен содержать порядковый номер сообщения, которые партнер ожидает получить следующим (например, последний Ns сообщения (non-ZLB) плюс 1, по модулю 65536). В то время как Nr в полученном ZLB используется для удаления сообщений из локальной очереди сообщений, ждущих imes повторной передачи в локальной очереди (смотри ниже), Nr следующего сообщения не должен обновляться при получении Ns ZLB.
Протокол надежной доставки принимающего партнера ответственен за проверку того, что управляющие сообщения доставлены на верхний уровень в правильном порядке и без дублирования. Сообщения, пребывающие в неверном порядке, могут быть занесены в очередь для последующей корректной доставки, когда пропущенные сообщения будут получены, или они могут быть выброшены, что вынудит партнера послать их повторно. Каждый туннель поддерживает очередь управляющих сообщений, которые нужно передать его партнеру. Сообщение в начале очереди посылается с заданным значением Ns, и хранится до тех пор, пока не придет от партнера управляющее сообщение, в котором поле Nr указывает на то, что данное сообщение получено. Если в течение определенного времени (рекомендуемое значение равно 1 секунде) отклика не получено, сообщение посылается повторно. Повторно посылаемое сообщение имеет то же значение Ns, но величина Nr должна быть сделана равной номеру очередного ожидаемого сообщения.
Каждая повторная посылка сообщения должна реализовываться по истечении задержки, величина которой возрастает экспоненциально от раза к разу. Таким образом, если первая повторная передача происходит спустя 1 секунду, следующая повторная передача может производиться по истечении 2 секунд, затем 4 секунд, и т.д.. Программная реализация может установить верхний предел на время между повторными пересылками сообщения. Этот предел должен быть не меньше 8 секунд. Если после нескольких повторных посылок, не зафиксировано никакого отклика от партнера, (рекомендуемое число попыток равно 5, но должно быть настраиваемым), туннель и все сессии должны быть аннулированы.
Когда туннель закрывается не по причине обрыва соединения, состояние и механизм надежной доставки должны поддерживаться и работать в течение всего периода повторных передач.
Механизм скользящего окна используется для передачи управляющих сообщений. Рассмотрим двух партнеров A & B. Предположим A задает размер приемного окна в сообщениях SCCRQ или SCCRP равным N. B при этом позволено иметь до N ожидающих подтверждения получения сообщений.
Когда N послано, нужно ждать подтверждения, которое сдвинет окно, прежде чем посылать новое управляющее сообщение. Программная реализация может поддерживать приемное окно с размером 1 (т.e., посылать AVP размера приемного окна со значением 1), но должно воспринимать от своего партнера окна с шириной до 4 (например, имеет возможность послать 4 сообщения, прежде чем остановиться и ожидать отклика). Значение 0 для AVP размера приемного окна является недопустимым.
При повторной передаче управляющих сообщений следует использовать медленный старт и окно подавления перегрузки. Рекомендуемая процедура для этого описана в приложении A.
Партнер не должен отказываться подтверждать сообщения, в качестве меры управления потоком управляющих сообщений. Предполагается, что реализация L2TP способна работать с входными управляющими сообщениями, возможно реагируя с ошибками, отражающими невозможность выполнения запрашиваемых действий. В приложении B представлены примеры управляющих сообщений, подтверждений и повторных передач.
Не специфицированный адрес
Адрес 0:0:0:0:0:0:0:0 называется не специфицированным адресом. Он не должен присваиваться какому-либо узлу. Этот адрес указывает на отсутствие адреса. Примером использования такого адреса может служить поле адреса отправителя любой IPv6 дейтограммы, посланной инициализируемой ЭВМ до того, как она узнала свой адрес.
Не специфицированный адрес не должен использоваться в качестве указателя места назначения IPv6 дейтограмм или в IPv6 заголовках маршрутизации.
Необходимые адреса узлов
ЭВМ должна распознавать следующие адреса, как обращенные к нему:
Её локальный адрес канала для каждого из интерфейсов
Выделенные уникаст-адреса
Адрес обратной связи
Мультикастинг-адрес для обращения ко всем узлам
Мультикастинг-адрес активного узла (solicited-node multicast address) для каждого из приписанных ей уникаст и эникастных адресов
Мультикаст-адреса всех групп, к которым принадлежит ЭВМ.
Маршрутизатор должен распознавать следующие адреса (as identifying itself):
Его локальный адрес канала для каждого из интерфейсов
Выделенные уникаст-адреса
Адрес обратной связи
Эникастные адреса маршрутизатора субсети для каналов, где он имеет интерфейсы.
Все другие эникастные адреса, которые использовались при маршрутизации.
Мультикастинг-адрес для обращения ко всем узлам
Мультикастинг-адрес для обращения ко всем маршрутизаторам
Мультикаст-адрес активного узла (solicited-node multicast address) для каждого приписанного ему уникаст и эникастного адресов.
Мультикастные адреса всех прочих групп, принадлежащих маршрутизатору.
Приложение должно предопределить только следующие адресные префиксы:
Не специфицированный адрес
Адрес обратной связи
Мультикаст-префикс (ff)
Локально используемые префиксы (link-local и site-local)
Предопределенные мультикаст-адреса
Префиксы, совместимые с IPv4
Приложения должны считать все остальные адреса уникастными, если противоположное не оговорено при конфигурации (например, эникастные адреса).
Необходимые эникаст-адреса
Эникаст-адрес маршрутизатора субсети предопределен и имеет формат, отображенный на рис. 4.4.1.1.12:
Рис. 4.4.1.1.12
Префикс субсети в эникастном адресе является префиксом, который идентифицирует определенный канал. Этот эникастный адрес является синтаксически идентичным уникастному адресу для интерфейса канала с идентификатором интерфейса равным нулю.
Пакеты, посланные группе маршрутизаторов с эникастным адресом, будут доставлены всем маршрутизатам субсети. При этом все маршрутизаторы субсети должны поддерживать работу с эникастными адресами. Реальный обмен будет осуществлен лишь с тем маршрутизатором, который ответит первым.
Эникастный адрес маршрутизатора субсети предполагается использовать в приложениях, где необходимо взаимодействовать с одним из совокупности маршрутизаторов удаленной субсети. Например, когда мобильный хост хочет взаимодействовать с одним мобильным агентом в его “домашней” субсети.
NIL
Специальный атом "NIL" представляет собой указание на отсутствие каких-то определенных данных типа строка или “список в скобках”. Его следует отличать от пустой строки "" или пустого “списка в скобках” ().
4. Операционные соображения
4.1. Присвоение имени почтовому ящику
Интерпретация имен почтовых ящиков является независимой от конкретной программной реализации. Однако имя почтового ящика INBOX является специальным именем, зарезервированным для "первичного почтового ящика данного пользователя на данном сервере" (значение не зависит от использования строчных или прописных букв). Почтовые ящики могут образовывать иерархическую структуру. Если желательно экспортировать иерархию имен почтовых ящиков, имена почтовых ящиков должны быть упорядочены по буквам слева направо.
Нотация ASN
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Одной из наиболее сложных систем сегодня являются открытые системы связи OSI (Open System Interconnection). OSI представляет собой достаточно формализованную стандартную архитектуру управления межкомпьютерными коммуникациями. Для описания этой системы была разработана абстрактный синтаксис нотаций ASN.1 (Abstract Syntax Notation; См. A Layman’s Guide to a Subset of ASN.1, BER, and DER. Burton S. Kaliski Jr., RSA Data Security, Inc. Redwood City, CA, 1991). ASN.1 является формальным языком, который обладает двумя основными чертами.
Используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами. Неотъемлемой частью ASN.1 являются базовые правила кодирования BER (Basic Encoding Rules), которые позволяют определить большое разнообразие типов данных. BER описывает то, как представить или закодировать любую величину в рамках стандарта ASN.1. Практически все величины здесь представляются в виде последовательности 8-битных октетов. Восьмой бит октета всегда считается самым старшим. BER позволяет закодировать величину более чем одним способом. Имеется также поднабор правил кодирования DER (Distinguished Encoding Rules, описаны в документе Х.509), которые определяют однозначные способы кодирования величин ASN.1.
Ниже приведены базовые правила обозначений метасинтаксиса ASN.1.
| n | (полужирный курсив) обозначает переменную |
| [] | (квадратные скобки, напечатанные полужирным шрифтом) указывают на то, что терм является опционным. |
| {} | (фигурные скобки, напечатанные полужирным шрифтом) группируют родственные термы. |
| | | (вертикальная черта, напечатанная полужирным шрифтом) выделяет альтернативные значения. |
| … |
(многоточие, напечатанное полужирным шрифтом) обозначает повторения. |
| = | (знак равенства, напечатанный полужирным шрифтом) описывает терм как субтерм. |
ASN.1 имеет четыре разновидности типов: простые типы, не имеющие компонент, структурные типы, имеющие компоненты, помеченные (tagged) типы, которые получаются из других типов, а также прочие типы, которые включают в себя типы CHOICE и ANY.
Типам и значениям могут присваиваться имена с помощью оператора (::=). Эти имена в дальнейшем могут использоваться для определения других типов и величин.
Все типы ASN.1 кроме CHOICE и ANY имеют метки, которые состоят из класса и неотрицательного кода метки. Типы ASN.1 тождественны, если их числовые метки совпадают. Существует четыре класса меток.
| universal | для типов, значения которых является неизменным для всех приложений. Эти типы определены в документе Х.208. |
| application | для типов со значением, специфическим для приложений, таких как служба каталогов Х.500. Типы двух разных приложений могут иметь одну и ту же метку и разные значения. |
| private | для типов, которые являются специфическими для данного предприятия. |
| content-specific | для типов со значением, специфическим для данного структурного типа. |
Ниже приведена таблица 4.4.13.2.1 типов и их меток универсального класса.
Таблица 4.4.13.2.1. Типы и их метки
| Тип | Комментарий | Цифровая метка (шестнадцатеричное) |
| INTEGER | Любое целое число | 02 |
| BIT STRING | Произвольная строка бит | 03 |
| OCTET STRING | Произвольная последовательность октетов | 04 |
| NULL | 0 | 05 |
| OBJECT IDENTIFIER | Последовательность целых компонент, идентифицирующих объект | 06 |
| SEQUENCE and SEQUENCE OF | 10 | |
| SET and SET OF | 11 | |
| PrintableString | Последовательность печатных символов | 13 |
| IA5String | Произвольная строка символов IA5 (ASCII) | 16 |
| UTCTime | Универсальное время (по Гринвичу; GMT) | 17 |
ASN.1 типы и значения выражаются в нотации, близкой к используемой в языках программирования. Множественные пробелы и разрывы строк рассматриваются как один пробел. Комментарии выделяются парами дефисов или парой дефисов и переводом строки. Идентификаторы (имена значений и полей) и имена типов состоят из букв, цифр и пробелов. Идентификаторы начинаются со строчной буквы, а имена типов - с прописной.
В SMI (Structure of Management Information) не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: INTEGER, OCTET STRING, OBJECT IDENTIFIER и NULL.
Стандарт ASN. 1 определяет форму представления информации и имен. Для строчных типов может быть введено ограничение на максимальный размер. В ASN.1 определено четыре структурированных типов:
| SEQUENCE | упорядоченный набор из одного или более типов. |
| SEQUENCE OF | упорядоченный набор из нуля или более представителей данного типа. |
| SET | неупорядоченный набор из одного или более типов. |
| SET OF | неупорядоченный набор из нуля или более представителей данного типа. |
Структурированные типы могут иметь опционные компоненты, в том числе со значениями по умолчанию.
Существуют типы помеченные явно и неявно. Неявно помеченные типы получаются из других типов путем изменения метки. Для неявной пометки используется ключевое слово IMPLICIT. Явно помеченные типы получаются из других типов путем добавления внешней метки. Помеченный явно тип - это структурированный тип, состоящий из одного компонента основного типа. Для явной пометки используется ключевое слово EXPLICIT. Пометка (тэгирование) весьма удобна для различия типов в пределах одного приложения.
Тип CHOICE обозначает объединение одного или более альтернатив. Тип ANY служит для обозначения произвольной величины для произвольного типа.
Правила BER определяют один или более способов представить любую величину в виде строки октетов. Существует три метода кодирования величин (в рамках BER): примитивный с известной длиной; конструктивный при известной длине и конструктивный при неизвестной длине. Выбор метода зависит от типа величины и от того, известна ли длина преобразуемой величины. Для простых не строчных типов используется примитивный метод кодирования. В каждом методе BER-кодирование имеет три или четыре части:
| Identifier octets | Определяет класс и числовую метку значения, а также указывает, является ли метод примитивным или конструктивным. |
| Length octets | Для методов кодирования с известной длиной определяет число октетов содержимого. |
| Contents octets | Для примитивных методов с заданной длиной дает конкретное выражение значения. |
| End-of-contents octets | Для конструктивных методов с неопределенной длиной указывает на конец содержимого. |
Примитивный метод кодирования с заданной длиной
Этот метод применим для простых типов и типов полученных из простых типов путем неявной пометки. Здесь необходимо, чтобы длина величины была известна заранее. Октеты идентификатора имеют два формата: для числовых меток от 0 до 31, и для числовых меток более 31. В первом случае биты 7 и 8 определяют класс (см. таблицу 4.4.13.2.2), бит 6 равен нулю, указывая на то, что метод кодирования primitive. Остальные биты используются для записи кода числовой метки. Во втором случае используется два или более октетов. В первом октете кодировка аналогична первому варианту за исключением того, что биты 1-5 содержат единицы.
Таблица 4.4.13.2.2. Коды классов
| Класс | Бит 8 | Бит 7 |
| Универсальный | 0 | 0 |
| Прикладной | 0 | 1 |
| Контекстно-ориентированный | 1 | 0 |
| Частный | 1 | 1 |
Для октетов длины примитивного метода имеется два формата: короткий (один октет для длин 0-127) и длинный (2-127 октетов). Для короткой формы 8-ой бит октета всегда равен нулю. Для длинной формы восьмой бит первого октета всегда равен 1, биты 1-7 содержат код числа дополнительных октетов длины. Старшая цифра записывается первой.
Конструктивный метод с заданной длиной
Этот метод используется для простых строчных и структурированных типов, типов, производных от простых строчных типов, и некоторых других. Здесь октеты идентификатора и октеты длины имеют формат, идентичный используемому примитивным методом, за исключением того, что бит 6 первого октета идентификатора равен 1.
Конструктивный метод кодирования с незаданной длиной
Метод используется для простых строчных типов, структурированных типов и типов, полученных из простых и структурированных типов с помощью неявной пометки. Октеты идентификатора идентичны предшествующему. Октет длины содержит код 80. Два октета конца содержательной части содержат 00 00.
Нотация типов, помеченных неявно, имеет вид:
[[class] number] IMPLICIT Type
class = UNIVERSAL | APPLICATION | PRIVITE
где Type - тип, class - опционное имя класса и number - цифровая метка (неотрицательное целое число).
Если имя класса отсутствует, тогда метка является контекстно-ориентированной. Такие метки могут появляться только в структурных компонентах или в типе CHOICE. Например:
PrivateKeyInfo ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey,
attributes [0] IMPLICIT Attributes OPTIONAL }
Здесь исходным (порождающим) типом является Attributes, класс отсутствует (т.е. контекстно-ориентированный), а числовая метка равна нулю. Кодирование компоненты attributes величины PrivateKeyInfo осуществляется следующим образом.
Октеты идентификатора равны 80, если значение порождающей величины Attributes имеет конструктивное BER-кодирование. Октеты длины и содержимого строго соответствуют октетам порождающей величины Attributes.
Непосредственная (явная) пометка используется для опционных компонент SEQUENCE c порождающим типом ANY и для компонент version типа Certificate (X.509 и RFC-1114). Нотация типов, помеченных явно, имеет формат.
[ [class] number] EXPLICIT Type
class = UNIVERSAL | APPLICATION | PRIVATE
где Type - тип, class - опционное имя класса, а number - числовая метка в пределах класса (неотрицательное целое число). Пример:
ContentInfo ::= SEQUENCE {
ContebtType ContentType,
Content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
Тип ContentInfo имеет опционную компоненту content с явной контекстно-ориентированной меткой. Здесь порождающим типом является ANY DEFINED BY contentType, класс отсутствует, а числовая метка в пределах класса равна 0.
Другим примером может являться тип Certificate [X.509], имеющий компоненту с явной контекстно-ориентированной меткой (ключевое слово EXPLICIT опущено).
Certificate ::= …
Version [0] Version DEFAULT v1988,
…
BER-кодирование величин, помеченных явно, является всегда конструктивным. Октеты содержимого идентичны соответствующим октетам порождающей величины. Например, BER-кодирование компоненты content величины ContentInfo имеет следующий вид.
Октеты идентификатора равны нулю, Октеты длины представляют длину BER-кодирования порождающей величины ANY DEFINED BY contentType.
Тип ANY
Тип ANY обозначает произвольную величину произвольного типа, где произвольный тип возможно определен при регистрации идентификатора объекта или является целочисленным индексом. Нотация типа ANY имеет формат:
ANY [DEINED BY identifier]
где identifier - опционный идентификатор. Форма ANY DEINED BY identifier может появиться только в компоненте типа SEQUNCE или SET, для которой identifier определяет какую-то другую компоненту и эта компонента имеет тип INTEGER или OBJECT IDENTIFIER. В этой форме истинный тип задается величиной этой другой компоненты. Например, тип AlgorithmIdentifier [X.509] имеет компоненту типа ANY:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL }
Здесь истинный тип компоненты parameter зависит от величины компоненты algorithm. Истинный тип будет определен при регистрации объекта величины идентификатора длякомпоненты algorithm.
Битовые строки
Тип BIT STRING обозначает произвольные битовые последовательности произвольной длины (включая ноль). Тип BIT STRING используется для цифровых сигнатур типа ExtendedCertificate или Certificate [X.509]. Нотация BIT STRING имеет формат.
BIT STRING
Например, тип SubjectPublicKeyInfo имеет компоненту типа BIT STRING:
SubjectPublicKeyInfo ::= SEQUENCE {
Algorithm AlgorithmIdentifier,
PublicKey BIT STRING }
BER-кодирование величины BIT STRING может быть примитивным или конструктивным. При примитивном кодировании первый октет содержимого несет в себе длину битовой строки в октетах. В последующих октетах записывается сама битовая последовательность. Процедура кодирования может включать в себя дополнение битовой строки до целого числа октетов нулями (если это необходимо). Строка делится на октеты.
При конструктивном кодировании октеты содержимого представляют собой соединение последовательности субстрок, только последняя из которых содержит код длины, выраженный в октетах. Например, при BER-кодировании значения BIT STRING “0111 1101 1001 1111 11” может быть представлена в одном из следующих видов, в зависимости от выбора схемы дополнения до целого числа октетов, от формата октетов длины и от метода кодирования примитивный/конструктивный).
| 03 04 06 7D 9F C0 | DER-кодирование |
| 03 04 06 7D 9F E0 | Дополнение кодом “100000” |
| 03 81 04 06 7D 9F C0 | Длинная форма представления октетов длины |
23 09 03 03 00 7D 9F 03 02 06 C0 | Конструктивное кодирование “01111101 1001 1111” +”11” |
/p> Первый октет первых трех представлений содержат код типа (для BIT STRING = 03). Второй октет в первых двух представлениях - код октетов длины (ведь далее следует 4 октета). Третий октет первой и второй строк содержит число добавленных нулей до числа бит, кратного восьми. Во втором байте третей строки записана 8, что указывает на длинную форму представления октетов длины. Последующая 1 говорит о том, что использован один дополнительный октет длины. Код длины в четвертом примере записан также во втором октете (далее следует 9 октетов). В этом варианте битовая строка разбита на две субстроки, первая из которых имеет длину в два октета. DER-кодирование предполагает всегда примитивный метод представления с дополнением строки нулями до длины, кратной целому числу октетов.
Тип CHOICE
Этот тип служит для объединения одной или более альтернатив. Нотация типа CHOICE имеет формат.
CHOICE {
[identifier1] Type1,
…,
[identifiern] Typen }
где identifier1, …, identifiern являются опционными идентификаторами альтернатив, а типы Type1, …, Typen - альтернативы. Идентификаторы нужны для документирования и не играют какой-либо роли при кодировании. Типы должны иметь определенные метки. Рассмотрим пример типа ExtendedCertificateOrCertificate, который относится к типу CHOICE.
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate, -- X.509 certificate
extendedCertificate [0] IMPLICIT ExtendedCertificate }
Здесь идентификаторами для альтернатив являются certificate и extendedCertificate, а сами альтернативы представлены типами Certificate и [0] IMPLICIT ExtendedCertificate. BER-кодирование для типа CHOICE сводится к кодированию альтернатив. При этом октеты идентификатора для рассмотренного примера содержат код 30, если выбранная альтернатива certificate, и A0 - в случае ExtendedCertificate.
Строки IA5
Тип IA5String представляет любые последовательности IA5-символов (международный алфавит 5 - эквивалентно ASCII). Длина строки может быть любой, включая нуль.
Этот тип используется для адресов электронной почты и неструктурированных имен. Нотация типа IA5String имеет простой формат.
IA5String
BER-кодирование величины IA5String может быть примитивным или структурированным. При примитивном кодировании октеты содержимого представляют собой символы IA5 в ASCII-кодов. При конструктивном кодировании октеты содержимого представляют собой соединение ряда IA5-субстрок. Рассмотрим примеры представления значения IA5-строки “test1@rsa.com”.
12 0D 74 65 73 74 31 40 72 73 61 2E 63 6F 6D | DER-кодирование |
| 12 81 0D 74 65 73 74 31 40 72 73 61 2E 63 6F 6D | Длинная форма октетов длины |
32 13 12 05 74 65 73 74 31 12 01 40 12 07 72 73 61 2E 63 6F 6D | Конструктивное кодирование: “test1” + “@” + “rsa.com” |
DER-кодирование является всегда примитивным, октеты содержимого идентичны случаю BER-кодирования.
Целое
Тип INTEGER представляет любые целые числа (положительные, отрицательные или 0). Тип INTEGER используется для номеров версий, криптографических параметров (показателей, модулей) и типов RSAPublicKey, RSAPrivatKey, DHParameter PBEParameter. Нотация типа INTEGER имеет формат:
INTEGER [{identifier1(value1) … identifiern(valuen) }]
где identifier1 … identifiern являются опционными идентификаторами, а value1… valuen опционные целые значения. Например, Version RFC-1114 относится к целому типу со значением:
Version ::= INTEGER { 1988(0) }
Идентификатору v1988 поставлено в соответствие значение 0. Тип Certificate RFC-1114 использует идентификатор v1988для присвоения значения по умолчанию компоненту version:
Certificate
version Version DEFAULT v1988,
…
BER-кодирование значения INTEGER является всегда примитивным. Октеты содержимого представляют значение целого по модулю 256 в форме дополнения по модулю 2. Старшая цифра является первой. Значение нуль кодируется одним октетом 00. Примеры BER-кодирования (совпадающего в данном случае с DER-кодированием) представлены в таблице 4.4.13.2.3.
Таблица 4.4.13.2.3. Примеры BER-кодирования
| Значение целого | BER-код |
| 0 | 02 01 00 |
| 127 | 02 02 00 7F |
| 128 | 02 02 00 80 |
| 256 | 02 02 01 00 |
| -128 | 02 01 80 |
| -129 | 02 02 FF 7F |
NULL
Тип NULL обозначает нулевую величину и предназначен для использования в качестве параметра алгоритмов. Нотация для типа NULL имеет формат:
NULL
Кодирование для типа NULL является всегда примитивным, октеты содержимого пусты. Например, BER-представление значения NULL может иметь одну из приведенных ниже форм (зависит от используемого представления октетов длины).
05 00
05 81 00
DER-кодирование типа NULL является также примитивным и совпадает с первой строкой приведенного выше примера.
Объектные идентификаторы
Тип OBJECT IDENTIFIER служит для обозначения дентификаторов, которые представляют собой последовательность целочисленных компонент, которые идентифицируют такие объекты, как алгоритм или атрибут имени каталога. Значение OBJECT IDENTIFIER может содержать любое число неотрицательных компонент. Этот тип не относится в числу строчных. Значения OBJECT IDENTIFIER присваиваются при регистрации.
Тип OBJECT IDENTIFIER используется для идентификации содержимого ContentInfo, алгоритмов в X.509 (AlgorithmIdentifier) и атрибутов Attribute и AttributeValueAssertion (X.501). Нотация OBJECT IDENTIFIER имеет формат.
OBJECT IDENTIFIER
Нотация величины OBJECT IDENTIFIER имеет вид:
{ [identifier] component1… componentn}
componenti = identifieri | identifieri (valuei) | valuei
где identifier, identifier1, … identifiern являются идентификаторами, а value1 …, valuen - опционные целые числа. Идентификаторы без целых значений могут встретиться только для объектов, описанных в Х.208.
Например, нижеприведенные величины объектных идентификаторов присвоены RSA DATA Security, Inc.
{ iso(1) member-body(2) 840 113549 }
{ 1 2 840 113549 }
В таблице 4.4.13.2.4 представлены некоторые объектные идентификаторы и их значения.
Таблица 4.4.13.2.4. Некоторые объектные идентификаторы и их значения
| Величина объектного идентификатора | Назначение |
| { 1 2 } | Члены ISO |
| { 1 2 840 } | US (ANSI) |
| { 1 2 840 113549} | RSA Data Security, Inc. |
| { 1 2 840 113549 } | RSA Data Security, Inc. PKCS (Public Key Cryptography Standard) |
| { 2 5 } | Служба каталогов (X.500) |
| { 2 5 8 } | Служба каталогов - алгоритмы |
BER- кодирование OBJECT IDENTIFIER является всегда примитивным. Октеты содержимого представляют собой объединение n-1 строки октетов, где n число компонент объектного идентификатора. Каждая октетная строка несет в себе целое число по модулю 128 (старшая часть первая). 8-ой бит каждого октета, кроме последнего, равен 1. Пусть value1, …, valuen целые значения компонентов объектного идентификатора. Тогда n-1 субидентификаторов, из которых формируется октетная строка, будут иметь следующий вид.
Первый субидентификатор равен 40value1 + value2. (значение value1 лежит в пределах 0-2 включительно, а value2 в интервале 0-39, когда value1 равна 0 или 1.
i-ый субидентификатор равен valuei+1 ; 2 Ј iЈ n-1.
Например, субидентификаторы объектного идентификатора RSA Data Security, Inc. равны 42 = 40ґ 1 + 2, 840, 113549 и 1. В шестнадцатеричном представлении BER-код этого объектного идентификатора имеет вид:
06 07 2A 86 48 86 F7 0D 01
DER-кодирование в данном случае совпадает с BER.
Строки октетов
Тип OCTET STRING служит для представления произвольных последовательностей октетов. Значение OCTET STRING может иметь любую длину, включая нуль. OCTET STRING используется для представления сообщений, включая зашифрованные, а также для типа PBEParameter. Нотация типа OCTET STRING имеет формат.
OCTET STRING [SIZE ({size | size1..size2})]
где size, size1 и size2 опционные ограничения размера. В форме OCTET STRING SIZE(size) строка октетов должна иметь октеты size. В формате OCTET STRING SIZE(size1 .. size2) строка должна содержать число октетов между size1 и size2. Например, тип PBEParameter имеет компоненту типа OCTET STRING:
PBEParameter ::= SEQUENCE {
salt OCTET STRING SIZE (8),
iterationCount INTEGER }
Здесь размер компоненты salt всегда равен 8 октетам. BER-кодирование типа OCTET STRING может быть примитивным или конструктивным. При примитивном кодировании октеты содержимого несут в себе октеты строки с первого по последний. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок значения OCTET STRING.
Например, BER- код значения OCTET STRING 01 23 45 67 89 AB CD EF может иметь один из следующих видов, в зависимости от формата октетов длины и вида кодирования (примитивное/конструктивное).
| 04 08 01 23 45 67 89 AB CD EF | DER-кодирование |
| 04 81 08 01 23 45 67 89 AB CD EF | Длинный формат октетов длины |
| 24 0С | Конструктивное кодирование |
| 04 04 01 23 45 67 | “01 23 45 67” + “89 AB CD EF” |
| 04 04 89 AB CD EF |
Строки печатных символов
Тип PrintableString предназначен для описания произвольных последовательностей печатных символов из набора:
A, B,…,Z
a,b,…,z
0,1,…,9
(пробел) ‘ () +, - . / : = ?
Этот тип используется для представления атрибутов имен (Х.520). Нотация типа PrintableString имеет вид:
PrintableString
BER-кодирование значения PrintableString может быть примитивным или конструктивным. При примитивном кодировании печатных символов байты содержимого несут в себе строки октетов печатных ASCII-кодов. При конструктивном кодировании содержимое октетов представляет собой последовательное объединение субстрок. Например, BER-код значения PrintableString “Test User 1” может быть представлено одним из ниже приведенных способов.
| 13 0B 54 65 73 74 20 55 73 65 72 20 31 | DER-кодирование |
| 13 81 0B 54 65 73 74 20 55 73 65 72 20 31 | Длинная форма октетов длины |
| 33 0F | Конструктивная форма, |
| 13 05 54 65 73 74 20 | “Test” + “User 1” |
| 13 06 55 73 65 72 20 31 |
Тип SEQUENCE
Тип SEQUENCE обозначает упорядоченную последовательность одного или более типов. Нотация типа SEQUENCE имеет вид:
SEQUENCE {
[identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
…,
[identifiern] Typen [{OPTIONAL | DEFAULT valuen}],
где identifier1 , …, identifiern являются опционными идентификаторами компонентов, Type1 , …, Typen - типы компонентов, а value1 ,…, valuen опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует.
Например, тип Validity [X.509] относится к типу SEQUENCE и имеет два компонента.
Validity ::= SEQUENCE {
start UTCTime,
end UTCTime }
Здесь start и end являются идентификаторами компонент, а типом компонент служит UTCTime. BER-кодирование значения SEQUENCE является всегда конструктивным. Октеты содержимого представляют последовательное объединение BER-кодов значений компонентов последовательности.
Тип SEQUENCE OF
Тип SEQUENCE OF обозначает упорядоченную последовательность из нуля или более компонентов данного типа, используется для имен в X.501. Нотация SEQUENCE OF имеет вид:
SEQUENCE OF Type
Так например, тип RNDSequence состоит из нуля или более компонент типа RelativeDistinguishedName.
RNDSequence ::= SEQUENCE OF RelativeDistinguishedName
BER-кодирование SEQUENCE OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов значений элементов последовательности в порядке их расположения. DER-кодирование имеет тот же формат.
Тип SET
Тип SET представляет собой неупорядоченное объединение из одного или более типов. Нотация типа SET имеет вид.
SET {
[identifier1] Type1 Type1 [{OPTIONAL | DEFAULT value1}],
…,
[identifiern] Typen [{OPTIONAL | DEFAULT valuen}],
где identifier1 , …, identifiern являются опционными идентификаторами компонентов, Type1 , …, Typen - типы компонентов, а value1 ,…, valuen опционные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются опционными. Квалификатор DEFAULT говорит о том, что величина компонента является опционной и ей присваивается определенное значение, если компонент отсутствует.
BER-кодирование для типа SET является всегда конструктивным. Октеты содержимого представляют последовательное объединение BER-кодов значений компонентов набора.
Тип SET OF
Тип SET OF представляет неупорядоченный набор, состоящий из нуля или более компонентов заданного типа и предназначенный для атрибутов PKCS (Public-Key Cryptography Standard) и имен X.501.
Нотация типа SET OF имеет вид:
SET OF Type
где Type - тип. Так тип RelativeDistinguishedName состоит из нуля или более компонентов типа AttributeValueAssertion.
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
BER-кодирование типа SET OF является всегда конструктивным. Октеты содержимого представляют собой объединение BER-кодов величин компонентов в порядке их исходного расположения. DER-кодирование также является всегда конструктивным, октеты содержимого представляются как и в случае BER-кодировки. Но компоненты лексикографически упорядочиваются.
Тип UTCTime
Тип UTCTime служит для обозначения универсального местного времени с привязкой по Гринвичу (GMT). Значение UTCTime характеризует местное время с точностью минут или секунд и временной сдвиг по отношению к GMT. Оно может иметь следующие формы:
YYMMDDhhmmZ
YYMMDDhhmm+hh`mm`
YYMMDDhhmm-hh`mm`
YYMMDDhhmmssZ
YYMMDDhhmmss+ hh`mm`
YYMMDDhhmmss- hh`mm`
где
| YY | младшие две цифры года |
| ММ | код месяца (01 - 12) |
| DD | код дня (01 - 31) |
| hh | код часа (00 - 23) |
| mm | код минут (00 - 59) |
| ss | код секунд (00 - 59) |
| Z | означает местное время по Гринвичу, + указывает на то, что местное время отстает от GMT, а - указывает на то, что местное время опережает GMT. |
| hh` | абсолютное значение смещения по отношению к GMT в часах |
| mm` | абсолютное смещение по отношению к GMT в минутах. |
UTCTime используется для определения типа Validity [X.509]. Нотация типа UTCTime имеет вид.
UTCTime
BER-кодирование значения UTCTime может быть примитивным или конструктивным. При примитивном кодировании октеты представляют собой символы строки в виде ASCII-кодов. При конструктивном кодировании октеты образуют объединение BER-кодов последовательных субстрок. В качестве примера рассмотрим варианты представления времени 4:45:40 после полудня 6 мая 1991 года (Pacific Daylight Time) в виде величины UTCTime.
“910506164540-0700”
“910506234540Z”
Это представление эквивалентно следующим BER-кодам:
17 0D 39 31 30 35 30 36 32 33 34 35 34 30 5A
17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30 30
DER- кодирование типа UTCTime всегда является примитивным.
Ниже приводится пример ASN.1 нотации имен типа X.501.
Name ::= CHOICE { RNDSequence }
RNDSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
AttributeValueAssertion ::= SEQUENCE { AttributeType, AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY
Тип Name идентифицирует объект в каталоге X.500. Name имеет тип CHOICE с одной альтернативой RNDSequence. Тип RNDSequence указывает проход по дереву каталогов X.500, начиная с корневой части. RNDSequence имеет тип SEQUENCE OF, состоящий из нуля или более компонентов RelativeDistinguishedName. Тип RelativeDistinguishedName присваивает уникальное имя объекту на дереве каталога. RelativeDistinguishedName имеет тип SET OF, состоящий из нуля или более компонентов AttributeValueAssertion. Тип AttributeValueAssertion присваивает значение атрибуту имени (например, определяющее принадлежность к стране). AttributeValueAssertion имеет тип SEQUENCE, состоящий из двух компонентов AttributeType и AttributeValue. AttributeType идентифицирует атрибут с помощью объектного идентификатора. AttributeValue присваивает значение атрибуту. Ниже предлагается пример DER-кодирования типа Name. В качестве имени использовано RSA Data Security, Inc. NOTARY (отдел Internet Privacy Enhanced Mail).
(root)
|
countryName = ”US”
|
organizationName = ”RSA Data Security, Inc.”
|
organizationalUnitName = ”NOTARY”
Каждый уровень соответствует одному значению RelativeDistinguishedName, в выбранном случае они имеют только одно значение AttributeValueAssertion. Значение AttributeType помещается до знака равенства, а AttributeValue (строка печатных символов с заданным типом атрибута) - после знака равенства.
Тип атрибута
DER-кодирование трех значений AttributeType согласно примитивному методу с заданной длиной дает следующие строки октетов.
| 06 03 55 04 06 | countryName |
| 06 03 55 04 0A | organizationName |
| 06 03 55 04 0B | organizationalUnitName |
Здесь countryName, organizationName и organizationalUnitName являются типами атрибутов Х.520, которые имеют следующие определения.
AttributeType OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
countryName OBJECT IDENTIFIER ::= { AttributeType 6 }
organizationName OBJECT IDENTIFIER ::= { AttributeType 10 }
organizationalUnitName OBJECT IDENTIFIER ::= { AttributeType 11 }
Октеты идентификатора имеют формат с меткой, так как метка равна 6 для OBJECT IDENTIFIER. Биты 8 и 7 равны 0, указывая на универсальный класс, бит 6 также равен 0, что говорит о примитивном методе кодирования. Октеты длины ориентированы на короткую форму представления. Октеты содержимого представляют собой объединения трех-октетных строк, полученных из субидентификаторов: 85 = 40x2 + 5; 4 и 6, 10 или 11.
Значение атрибута
DER-кодирование трех значений AttributeValue в соответствии с примитивным методом при заданной длине дает следующие строки:
| 13 02 55 53 | “US” |
| 13 17 52 53 41 20 | “RSA |
| 44 61 74 61 20 | Data |
| 53 65 63 75 72 69 74 79 2C 20 | Security, |
| 49 6E 63 2E | Inc.” |
Метка равна 19 (PrintableString) биты 8 и 7 равны 0, указывая на универсальный класс, бит 6 также равен 0, отмечая примитивный метод кодирования. Октеты длины имеют “короткий” формат, а октеты содержимого являются ASCII-представлением значения атрибута.
Атрибут ValueAssertion
DER-кодирование трех значений AttributeValueAssertion в соответствии с конструктивным методом дает следующие строки октетов.
30 09 06 03 55 04 06 13 02 55 53 | countryName = “US” |
30 1E 06 03 55 04 0A 13 17 52 53 41 20 44 61 74 61 20 53 65 63 75 72 69 74 79 2C 20 49 6E 63 2E | organizationName = “RSA Data Security, Inc.” |
30 0D 06 03 55 04 0B 13 06 4E 4F 54 41 52 59 | organizationalUnitName = “NOTARY” |
Октеты идентификатора используют короткий формат (low-octet form), так как для SET OF метка равна 17. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют “короткому” формату, а октеты содержимого представляют собой объединение DER-кодов компонент attributeType и attributeValue.
RelativeDistinguishedName</p>
DER- кодирование трех значений RelativeDistinguishedName, выполняемое согласно конструктивному методу, дает следующие строки октетов.
31 0B
| 30 09 … 55 53 |
31 20
| 30 1E … 63 2E |
31 0F
| 30 0D … 52 59 |
Октеты идентификатора используют короткий формат (low-octet form), так как для SET OF метка равна 17. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют “короткому” формату, а октеты содержимого представляют собой объединение DER-кодов компонент AttributeValueAssertion.
RDNSequence
DER-кодирование значений RDNSequence, выполняемое согласно конструктивному методу при заданной длине, дает следующие строки октетов.
30 40
31 0B … 55 53
31 20 … 63 2E
31 0F … 52 59
Октеты идентификатора используют короткий формат (low-octet form), так как для SEQUENCE OF метка равна 16. Биты 8 и 7 равны 0 (универсальный класс), а бит 6 равен 1 (конструктивное кодирование). Октеты длины следуют “короткому” формату, а октеты содержимого представляют собой объединение DER-кодов трех компонент RelativeDistinguishedName в порядке их следования.
Name
DER-кодирование значений Name выполняется аналогично значениям RDNSequence и выдает следующие результаты.
30 40 31 0B 30 09 06 03 55 04 06
13 02 55 53 31 20 30 1E 06 03 55 04 0A
13 17 52 53 41 20 44 61 74 61 20 53 65 63 75 72 69 74 79 2C 20 49 6E 63 2E 31 0F 30 0D 06 03 55 04 0B
13 06 4E 4F 54 41 52 59
NSAP адреса
Соответствие NSAP адреса IPv6 адресам выглядит следующим образом (рис. 4.4.1.1.7):
Рис. 4.4.1.1.7
О протоколе верхнего уровня Контрольные суммы верхнего уровня
Любой транспортный или другой протокол верхнего уровня, который включает адреса IP-заголовка в свою контрольную сумму, должен быть модифицирован, чтобы работать с 128-битовыми IPv6адресами вместо 32-битовых IPv4. В частности, ниже показаны псевдо-заголовки для TCP и UDPв IPv6 (рис. 4.4.1.1.26):
Рис. 4.4.1.1.26. Формат псевдо-заголовков для TCP и UDP
Если пакет содержит заголовок маршрутизации, в качестве адреса места назначения в псевдо-заголовке используется оконечный адрес. В исходном узле этот адрес будет последним элементом заголовка маршрутизации; для узла получателя он будет находиться в поле адрес места назначения IPv6 заголовка.
Код поля следующий заголовок в псевдо-заголовке идентифицирует протокол верхнего уровня (например, 6 для TCPили 17 для UDP). Он будет отличаться от кода поля следующий заголовок в IPv6 заголовке, если имеются заголовки расширения между заголовком IPv6 и заголовком протокола верхнего уровня.
В качестве кода длины поля данных в псевдо-заголовке используется длина пакета протокола верхнего уровня, включая заголовок верхнего уровня. Он будет меньше длины поля данных в заголовке (или в опции Jumbo Payload), если имеются заголовки расширения между IPv6 заголовком и заголовком верхнего уровня.
В отличие от IPv4, при формировании udp пакетов в IPv6 узле, контрольная сумма не является опционной. Поэтому при формировании UDP-пакета IPv6 узел должен вычислить контрольную UDP сумму пакета и псевдо-заголовка и, если вычисление дает в качестве результата нуль, он должен быть заменен на ffff для помещения в UDP заголовок. IPv6-получатели должны выбрасывать UDP пакеты, содержащие нулевую контрольную сумму и фиксировать при этом состояние ошибки.
IPv6 версия ICMP-пакетов [RFC-1885] включает псевдо-заголовок в вычисление контрольной суммы; это отличается от IPv4 версии ICMP, которая не включает псевдо-заголовок в контрольную сумму. Причина изменения связана с попыткой защитить ICMP от некорректной доставки или искажений важных полей в IPv6 заголовке, который в отличие от IPv4 не защищен контрольным суммированием на интернет-уровне. Поле следующий заголовок в псевдо-заголовке для ICMP содержит код 58, который идентифицирует IPv6 версию ICMP.
О размере пакетов
Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.
Для каждого канала, с которым связан узел непосредственно, он должен быть способен принимать пакеты с размером MTU данного канала. В каналах, которые можно конфигурировать, например, PPP [RFC-1661], должно быть установлено MTU не менее 576 октетов; рекомендуется устанавливать максимально возможное MTU, чтобы позволить инкапсуляцию (туннелирование) без привлечения фрагментации.
Настоятельно рекомендуется, чтобы узлы IPv6 использовали механизм определения MTU пути [RFC-1191] для использования преимущества большого значения MTU. Однако в минимальной конфигурации IPv6 (например, в BOOT ROM) может ограничивать себя в пределах 576 октетов и не использовать path MTU discovery.
Для того чтобы послать пакет длиннее чем MTU канала, узел может использовать заголовок фрагментации IPv6. Однако использование такой фрагментации заблокировано в приложениях, где используется настройка по измеренному значению MTU пути.
Узел должен быть способен принимать фрагментированные пакеты, которые после сборки имеют размер 1500 октетов, включая IPv6 заголовок. Узлу позволено принимать пакеты, которые после сборки имеют размер более 1500 октетов. Однако узел не должен посылать фрагменты, которые после сборки образуют пакеты длиннее 1500 октетов, если он не уверен, что получатель способен их воспринять и дефрагментировать.
В ответ на IPv6 пакет, посланный IPv4 адресату (т.e., пакет, который подвергается преобразованию из IPv6 в IPv4), узел отправитель IPv6 может получить ICMP сообщение packet too big, предупреждающее о том, что MTU следующего узла меньше 576. В этом случае узел IPv6 не должен уменьшать размер пакетов до 576 октетов, он должен включить в эти пакеты заголовок фрагментации, так чтобы маршрутизатор, выполняющий трансляцию IPv6-IPv4, мог получить приемлемый код идентификации, чтобы использовать полученные IPv4 фрагменты. Заметьте, что это означает сокращение длины поля данных до 528 октетов (576 минус 40 для IPv6-заголовка и 8 для заголовка фрагментации), и меньше, если имеются другие заголовки расширения.
Замечание: Анализ MTU пути должно проводиться даже в случае, когда узел “думает”, что адресат находится на том же канале что и сам узел.
Замечание: В отличие от IPv4, в IPv6 не нужно устанавливать флаг "don't fragment" (не фрагментировать) в заголовках пакетов, для того чтобы выполнить операцию определения величины mtu канала; так как это является атрибутом любого IPv6 пакета по умолчанию. Части процедур из RFC-1191, которые включают в себя использование таблиц MTU, не применимы к IPv6, так как версия сообщения IPv6 "datagram too big" всегда указывает на точное значение MTU, которое следует использовать.
Обязательные AVP
Получение неизвестной AVP, которая имеет бит M=1, является катастрофическим для сессии или туннеля, с которым она ассоциирована. Таким образом, бит M должен быть определен только для AVP, которые критичны для нормальной работы сессии или туннеля. Далее, в случае, когда LAC или LNS получают неизвестную AVP с M-битом равным 1 и закрывают сессию или туннель, ответственность за это полностью несет партнер, пославший обязательную AVP. Прежде чем определить AVP с M=1, в особенности AVP специфичное для данного производителя, убедитесь в том, что вы именно этого хотите.
Когда имеется адекватная альтернатива использованию M-бита, ей следует воспользоваться. Например, вместо того, чтобы посылать AVP с M=1 для определения существования специфического расширения, можно решить проблему путем посылки AVP в сообщении-запросе в расчете на получение соответствующего AVP в отклике.
Использование M-бита с новыми AVP (не определенными в этом документе) должно предоставить возможность сконфигурировать программу так, чтобы AVP либо не посылалась, или посылалась с M-битом равным нулю.
Обзор AVP
Имя AVP является списком, указывающим типы сообщений, которые использует каждая AVP. После каждого названия AVP следует короткое описание назначения AVP, подробности формата значения атрибута, и любая дополнительная информация, необходимая для правильного использования AVP.
Обзор протокола
L2TP использует два вида пакетов, управляющие и информационные сообщения. Управляющие сообщения используются при установлении, поддержании и аннулировании туннелей и вызовов. Информационные сообщения используются для инкапсуляции PPP-кадров пересылаемых по туннелю. Управляющие сообщения используют надежный контрольный канал в пределах L2TP, чтобы гарантировать доставку (смотри раздел 5.1). Информационные сообщения если происходит их потеря, не пересылаются повторно.
| PPP кадры | ||
| L2TP Информационные сообщения |
L2TP Управляющие сообщения | |
| L2TP Информационный канал (ненадежный) | L2TP Канал управления (надежный) | |
| Транспортировка пакетов (UDP, FR, ATM, etc.) | ||
Рис. 2.0. Структура протокола L2TP
На рис. 2.0 показано взаимоотношение PPP-кадров и управляющих сообщений по управляющему и информационному каналам L2TP. PPP-кадры передаются через ненадежный канал данных, инкапсулированные сначала в L2TP, а затем в транспортные пакеты, такие как UDP, Frame Relay, ATM и т.д.. Управляющие сообщения посылаются через надежный управляющий канал L2TP, который передает пакеты в пределах того же пакетного транспорта.
Порядковые номера необходимы во всех управляющих сообщениях и используются в управляющем канале для обеспечения надежной доставки. Информационные сообщения могут использовать порядковые номера, чтобы восстановить порядок пакетов и детектировать потерю кадров. Все коды посылаются в порядке, принятом для сетей (старшие октеты первые).
Одновременное исполнение нескольких команд
Клиент может послать другую команду, не дожидаясь отклика на предшествующую, сервер может начать обработку другой команды до завершения обработки текущей.
Исключение может составлять случаи, когда результат выполнения одной команды зависит от выполнения других команд. Клиенты не должны посылать несколько команд, не дожидаясь результата, если возможна неопределенность из-за их взаимозависимости. Если сервер детектирует возможную неопределенность, он должен исполнить их последовательно в порядке их получения от клиента.
Наиболее очевидный пример неопределенности реализуется, например, когда последовательно выполняются команды FETCH для флагов сообщения и STORE для тех же самых флагов.
Неочевидные неопределенности возникают с командами, которые допускают немаркированный отклик EXPUNGE (команды отличные от FETCH, STORE и SEARCH), так как немаркированный отклик EXPUNGE может нарушить корректность порядковых номеров сообщений для последующих команд. Это не представляет проблем для команд FETCH, STORE или SEARCH, так как серверам запрещено посылать отклики EXPUNGE, когда исполняется одна их этих команд. Следовательно, если клиент посылает любую команду, отличную от FETCH, STORE или SEARCH, он должен ждать отклика, прежде чем посылать команду, содержащую номер сообщения. Например, следующая последовательность команд (без ожидания) является некорректной:
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
Ниже представлены примеры последовательностей, не требующих ожидания завершения предшествующих инструкций:
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
Опции
Два из определенных в настоящее время заголовков расширения - заголовок опций hop-by-hop и заголовок опций места назначения - несут в себе переменное число TLV-кодированных (type-length-value) опций следующего формата (Рис. 4.4.1.1.16):
Рис. 4.4.1.1.16 Формат опций
| Тип опции | 8-битовый идентификатор типа опции. |
| Длина опции | 8-битовое целое число без знака. Длина поля данных опции в октетах. |
| Данные опции | Поле переменной длины. Данные зависят от типа опции. |
Последовательность опций в заголовке должна обрабатываться строго в соответствии с их порядком записи.
Идентификаторы типа опций кодируются так, что их старшие два бита характеризуют операцию, которая должна быть выполнена, если узел не узнает тип опции:
| 00 |
обойти эту опцию и продолжить обработку заголовка. |
| 01 | выбросить данный пакет. |
| 10 |
выбросить данный пакет и вне зависимости от того, является ли адрес назначения мультикастинговым, послать отправителю ICMP-пакет с кодом parameter problem (код=2), с указателем на не узнанный код опции. |
| 11 | выбросить данный пакет и, если адрес места назначения не мультикастинговый, послать отправителю icmpпакет с кодом parameter problem (код=2) с указателем на не узнанный код опции. |
Третий старший бит типа опции определяет, может ли информация в поле опция измениться по пути до места назначения пакета. Когда в пакете присутствует заголовок аутентификации, для любой опции, информация которой может измениться по пути, должна рассматриваться как нулевые октеты при определении значения идентификации. Значения этого бита:
0 - Данные опции не меняют маршрута
1 - Информация опции может изменить маршрут.
Отдельные опции могут требовать определенного выравнивания, с тем, чтобы обеспечить выкладку мультиоктетного значения данных поля опции. Требование выравнивания опции описывается с помощью выражения xn+y, означающего, что поле тип опции должно находиться через целое число, кратное x октетам плюс y октетов (отсчет от начала заголовка). Например:
| 2n |
означает любое двухоктетное смещение от начала заголовка. |
| 8n+2 | означает любое 8-октетное смещение от начала заголовка плюс 2 октета. |
Существует две опции заполнения, которые используются, когда необходимо выровнять последующие опции и вывести границу заголовка на значение кратное 8 октетам. Эти заполняющие опции должны распознаваться всеми приложениями IPv6:
Опция Pad1 (выравнивание не требуется)
Опция Pad1 используется для введения одного октета заполнителя в зону опций заголовка. Если требуется более одного октета, используется опция Padn.
Опция padn (выравнивание не требуется)
Рис. 4.4.1.1.17
Опция Padn используется для введения двух и более октетов заполнителей в поле опций заголовка. Для n октетов заполнителя поле OPT data Len содержит значение n-2, а поле данных опции состоит из n-2 нулевых октетов
Опции заголовка Hop-by-Hop (шаг за шагом)
Заголовок опций hop-by-hop (шаг за шагом) используется для опционной информации, которая просматривается каждым узлом по пути доставки. Заголовок опций hop-by-hop идентифицируется кодом поля следующий заголовок 0 в IPv6 заголовке и имеет формат (рис. 4.4.1.1.18):
Рис. 4.4.1.1.18. Формат заголовка опций hop-by-hop
| Следующий заголовок | 8-битовый селектор. Определяет тип заголовка, который следует непосредственно за заголовком опций hop-by-hop. Использует те же значения поля протоколов, что и IPv4 [RFC-1700] |
| HDR EXT LEN | 8-битовое число без знака. Длина заголовка поля опций hop-by-hop в октетах, исключая первые 8 октетов. |
| Опции | Поле переменной длины. Содержит один или более TLV-закодированных опций. |
В дополнение к Pad1 и Padn опциям определены следующие опции hop-by-hop:
| Опция Jumbo Payload | (необходимо выравнивание: 4n + 2) |
Рис. 4.4.1.1.19.
Опция Jumbo payload используется для посылки пакетов IPv6 с полем данных, превосходящим 65535 октетов. Длина Jumbo Payload характеризует длину пакета в октетах, исключая заголовок IPv6, но включая заголовок опций hop-by-hop; Это поле должно содержать код более чем 65535. Если получен пакет с опцией Jumbo payload, содержащей код длины меньше или равный 65535, посылается сообщение ICMP (parameter problem, код 0) с указателем на старший октет поля длины Jumbo payload.
Поле длины Payload length IPv6 заголовка должно быть равно нулю для каждого пакета с опцией Jumbo payload. Если получен пакет с корректным значением опции Jumbo Payload и ненулевым кодом длины поля данных, посылается сообщение ICMP (parameter problem код 0) с указателем на поле тип опции.
Опция Jumbo payload не может использоваться в пакетах, которые несут в себе заголовок фрагмента. Если заголовок фрагмента встретится в пакете, содержащем корректную опцию jumbo payload, посылается сообщение ICMP (parameter problem, код 0) с указателем на первый октет заголовка фрагмента.
Приложения, которые не поддерживают опцию Jumbo Payload, не могут иметь интерфейсы для каналов с MTU больше 65575 (40 октетов IPv6 заголовка плюс 65535 октетов данных).
Операции клиента SNTP
Клиент SNTP может работать в мультикастном, уникастном и эникаситном режимах. В мультикастном режиме клиент не посылает никаких запросов и ждет широковещательных сообщений (режим 5) от специально выделенного мультикастного сервера. В уникастном режиме клиент посылает запросы (режим 3) специально выделенному серверу и ожидает от него откликов (режим 4). В эникастном режиме клиент посылает запросы (режим 3) по специально выделенному местному широковещательному или мультикастному адресу и ожидает откликов (режим 4) от одного или более эникастных серверов. Клиент использует первый полученный отклик и устанавливает с соответствующим сервером связь в уникастном режиме. Последующие отклики от данного, или других серверов игнорируются. Запросы номинально посылаются с интервалом от 64 до 1024 секунд, в зависимости от стабильности частоты клиента и от требуемой точности.
Уникастные или эникастные клиенты используют заголовок сообщения NTP, посылают запрос серверу и считывают время дня из поля Transmit Timestamp отклика. Для этой цели все поля заголовка NTP могут быть установлены равными нулю, за исключением первого октета и (опционно) поля Transmit Timestamp. В первом октете поле LI устанавливается равным 0 (никаких предупреждений), а в поле режим заносится код 3 (клиент). Поле VN должно соответствовать номеру версии сервера NTP/SNTP; однако, серверы V.4 воспринимают и предыдущие версии. Серверы V.3 (RFC-1305) и версии 2 (RFC-1119) воспринимают предшествующие версии, включая версию 1 (RFC-1059). Версия 0 (RFC-959) в настоящее время уже не поддерживается.
Рекомендуется чтобы клиенты использовали последнюю версию, которую поддерживает выбранный сервер.
Чтобы вычислить полную циклическую задержку d и смещение локальных часов по отношению к серверу t, клиент устанавливает значение поля transmit timestamp в запросе равным времени дня согласно часам клиента и в соответствии с форматом временных меток NTP. Сервер копирует этот код в поле originate timestamp отклика и устанавливает поле receive timestamp и transmit timestamp в соответствии с показанием своих часов.
Когда будет получен отклик от сервера, клиент определяет значение переменной Destination Timestamp, как время прибытия по своим часам. В таблице 4.4.16.5. рассмотрены все 4 типа временных меток.
Таблица 4.4.16.5. Типы временных меток
| Имя временной метки | ID | Когда генерируется |
| Originate Timestamp (исходная метка) | T1 | Время отправки запроса клиента |
| Receive Timestamp (метка получения) | T2 | Время получения запроса сервером |
| Transmit Timestamp (метка посылки) | T3 | Время посылки отклика сервером |
| Destination Timestamp (метка назначения) | T4 | Время получения отклика клиентом |
Циклическая (roundtrip) задержка d и смещение локальных часов t определяются как:
d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.
В таблице 4.4.16.6. собраны операции клиента в уникаст, эникаст и мультикаст режимах. Рекомендуемые проверки ошибок представлены в колонках таблицы “Отклик” и “Мультикаст”. Сообщение следует рассматривать как корректное только в случае, если все поля содержат допустимые коды. Следует ли воспринимать сообщение, если оно содержит неверные значения для поля (ей), помеченного ремаркой “Игнорируется”, зависит от конкретной реализации программы.
Таблица 4.4.16.6. Операции клиента и значения полей заголовка
| Имя поля | Уникаст/Эникаст | Мультикаст | |
| Запрос | Отклик | ||
| LI | 0 | 0-2 | 0-2 |
| VN (номер версии) | 1-4 | копируется из запроса | 1-4 |
| Режим | 3 | 4 | 5 |
| Слой | 0 | 1-14 | 1-14 |
| Запрос | 0 | Игнорируется | Игнорируется |
| Точность | 0 | Игнорируется | Игнорируется |
| Root Delay | 0 | Игнорируется | Игнорируется |
| Root Dispersion | 0 | Игнорируется | Игнорируется |
| Reference Identifier | 0 | Игнорируется | Игнорируется |
| Reference Timestamp | 0 | Игнорируется | Игнорируется |
| Originate Timestamp | 0 | (смотри текст) | Игнорируется |
| Receive Timestamp | 0 | (смотри текст) | Игнорируется |
| Transmit Timestamp | (смотри текст) | не равно нулю | не равно нулю |
| Аутентификатор | опционно | опционно | опционно |
Операции сервера SNTP
Сервер SNTP может работать в уникастном, эникастном или мультикастном режимах, а также реализовать любую из комбинаций этих режимов. В уникаст и эникаст режимах сервер получает запросы (режим 3), модифицирует определенные поля в заголовке NTP, и посылает отклик (режим 4), возможно используя тот же буфер сообщения, что и в случае запроса. В режиме эникаст сервер прослушивает определенный широковещательный или групповой мультикаст-адрес, определяемый IANA, но использует свой собственный уникастный адрес в поле адреса отправителя отклика. За исключением выбора адреса в отклике работа сервера в эникаст и уникаст режима идентична. Мультикастные сообщения обычно посылаются с интервалом от 64 до 1024 сек, в зависимости от стабильности часов клиента и требуемой точности.
В эникаст и уникаст режимах поля VN и регистрация (Poll) запроса копируются без изменений в отклик. Если поле режим запроса содержит код 3 (клиент), оно делается в отклике равным 4 (сервер); в противном случае в это поле записывается 2 (симметричный пассивный), для того чтобы обеспечить соответствие со спецификацией NTP. Это позволяет клиентам, сконфигурированным для симметричного активного режима (режим 1) успешно работать, даже если конфигурация не является оптимальной. В мультикастном режиме в поле VN заносится код 4, в поле режим код 5 (широковещательный) и в поле регистрация целая часть значение логарифма по основанию 2 от длительности периода посылки запросов.
Заметим, что крайне желательно чтобы серверы, поддерживающие мультикастинг, поддерживали и уникастный режим. Это необходимо для измерения RTT клиент/сервер, прежде чем осуществлять регулярный обмен в мультикастном режиме.
В уникастном и эникастном режимах сервер может реагировать, а может и игнорировать запросы, если не синхронизован надлежащим образом с помощью радио-часов. Но предпочтительным поведением является присылка отклика в любом случае, так как позволяет убедиться в достижимости сервера. В мультикастном режиме сервер посылает широковещательные сообщения, только если он синхронизован.
Остальные поля заголовка NTP заполняются следующим образом. Если сервер синхронизован и функционирует правильно, в поле LI заносится 0, а в поле слой - 1 (первичный сервер). Если это не так, в поле слой записывается 0, а в поле LI - 3. В поле точность заносится код, характеризующий точность локальных часов. Для всех практических случаев этот код вычисляется, как отрицательное число бит справа от запятой в формате временной метки NTP. Поля Root Delay и Root Dispersion для первичного сервера делаются равными 0. Поле Root Dispersion опционно может быть сделано равным значению, соответствующему максимальной ожидаемой ошибке радио-часов. В поле Reference Identifier заносится идентификатор первичного эталона времени, как это указано в таблице 4.4.16.4.
Поля временных меток заполняются следующим образом. Если сервер не синхронизован или только что включился, все временные метки устанавливаются равными нулю. Если сервер синхронизован, в поле Reference Timestamp записывается время последней коррекции по радио-часам или модему. В уникастном и эникастном режимах в поля Receive Timestamp и Transmit Timestamp заносится время дня, когда было послано сообщение, а в поле Originate Timestamp записывается неизмененная копия поля Transmit Timestamp из запроса. В мультикастном режиме в поля Originate Timestamp и Receive Timestamp заносится 0, а в Transmit Timestamp время дня, когда послано сообщение. В таблице 4.4.16.7 представлены все перечисленные операции.
Таблица 4.4.16.7
| Имя поля | Уникаст/Эникаст | Мультикаст | |
| Запрос | Отклик | ||
| LI | игнорируется | 0 или 3 | 0 или 3 |
| VN | 1-4 | копия из запроса | 4 |
| Режим | 3 | 2 или 4 | 5 |
| Слой | игнорируется | 1 | 1 |
| Регистрация | игнорируется | копия из запроса | log2 периода запросов |
| Точность | игнорируется | -log2 числа значащих бит сервера | -log2 числа значащих бит сервера |
| Root Delay | игнорируется | 0 | 0 |
| Root Dispersion | игнорируется | 0 | 0 |
| Идентификатор эталона | игнорируется | Идентификатор эталона | Идентификатор эталона |
| Reference Timestamp | игнорируется | время последней коррекции по радио-часам | время последней коррекции по радио-часам |
| Originate Timestamp | игнорируется | копируется из поля transmit timestamp | 0 |
| Receive Timestamp | игнорируется | время дня | 0 |
| Transmit Timestamp | (см. текст) | время дня | время дня |
| Аутентификатор | опционно | опционно | опционно |
Наиболее важным индикатором неисправности сервера является поле LI, в котором код 3 указывает на отсутствие синхронизации. Когда получено именно это значение, клиент должен проигнорировать сообщение сервера вне зависимости от содержимого других полей.
Определение новой ресурсной записи и домена
Определен новый тип ресурсной записи для хранения IPv6-адреса ЭВМ. Если ЭВМ имеет более одного IPv6-адреса, тогда используется более одной такой ресурсной записи.
Тип ресурсной записи aaaa является специфическим для класса Интернет и служит для записи одного IPv6-адреса. Код типа равен 28 (десятичное).
128-битовый IPv6-адрес записывается в информационной части ресурсной записи aaaa, придерживаясь порядка байт, используемого в сети (старший байт первый).
Запрос aaaa для конкретного имени домена в классе Интернет возвращает в качестве отклика все ресурсные записи, соответствующие ресурсной секции aaaa. Запрос типа aaaa не выполняет никакой дополнительной обработки этой секции.
Текстовое представление информационной секции ресурсной записи aaaa, используемое в файле базы данных имеет формат, описанный в [3], а также в текущем разделе.
Определен специальный домен, который предназначен для установления соответствия между именами и IPv6-адресами. Домен имеет имя ip6.int.
IPv6-адрес представляется в виде имени в домене ip6.int. Это имя выглядит как последовательность символов, разделенных точками, завершающаяся суффиксом .ip6.int. Последовательность символов записывается в обратном порядке, т.е. младший по порядку символ записывается первым и т.д... Каждый из символов представляет собой шестнадцатеричную цифру. Например, запрос, соответствующий адресу
4321:0:1:2:3:4:567:89ab
будет выглядеть как
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int.
Отклик BAD
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик BAD отмечает сообщение об ошибке со стороны сервера. В маркированной форме он сообщает об ошибке протокольного уровня в команде клиента; метка отмечает команду, которая вызвала ошибку. Непомеченная форма указывает на ошибку протокольного уровня, для которой нельзя указать команду, вызвавшую ошибку; это может также означать внутреннюю ошибку сервера. Текстовое сообщение описывает условия.
Пример: C: ...very long command line...
S: * BAD Command line too long
C: ...empty line...
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed
Отклик BYE
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик BYE является всегда непомеченным, он указывает, что сервер намеривается разорвать соединение. При этом пользователю может быть послано текстовое сообщение, проясняющее статус клиента. Отклик BYE посылается при выполнении одного из четырех условий:
Как часть нормальной процедуры logout. Сервер закроет соединение после отправки маркированного отклика OK на команду LOGOUT.
Как уведомление об аварийном прерывании сессии. Сервер немедленно разрывает соединение.
Как уведомление о процедуре автоматического logout по причине отсутствия активности. Сервер немедленно разрывает соединение.
Как одно из трех возможных сообщений при установлении соединения, уведомляя, что сервер не может установить соединение с данным клиентом. Сервер немедленно разрывает соединение.
Отличие между откликом BYE, который является частью обычной процедуры LOGOUT (первый вариант), и BYE при отказе (остальные три варианта), заключается в том, что соединение в последнем случае разрывается немедленно.
Пример: S: * BYE Autologout; idle for too long
Отклик CAPABILITY
Содержимое: список возможностей.
Отклик CAPABILITY возникает в результате исполнения одноименной команды. Список возможностей, содержащийся в перечне наименований, разделенных пробелами, характеризует функции, поддерживаемые сервером. Список возможностей должен включать в себя атом "IMAP 4.1".
Имя возможности, которое начинается с "AUTH=" указывает, что сервер поддерживает данный механизм аутентификации. Другие наименования возможностей отмечают, что сервер поддерживает расширение, модификацию или усовершенствования протокола IMAP 4.1. Отклик сервера должен соответствовать данному документу до тех пор, пока клиент использует команды, согласованные со списком возможностей.
Имена возможностей должны либо начинаться с "X", либо быть стандартными, либо соответствовать расширениям IMAP 4.1, модификациям или усовершенствованиям, зарегистрированным IANA. Сервер не должен предлагать незарегистрированные или нестандартные имена возможностей, если их имена не начинаются с символа "X".
Реализациям клиента не следует требовать каких-либо имен возможностей, отличных от "IMAP 4.1", они должны игнорировать неизвестные имена возможностей.
Пример: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
Отклик EXISTS
Содержимое: отсутствует.
Отклик EXISTS сообщает о числе сообщений в почтовом ящике. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение). Отклик EXISTS должен регистрироваться клиентом.
Пример: S: * 23 EXISTS
Отклик EXPUNGE
Содержимое: отсутствует.
Отклик EXPUNGE уведомляет, сообщение с каким порядковым номером удалено из почтового ящика. Порядковые номера последующих сообщений немедленно уменьшаются на единицу.
Как результат этого немедленного уменьшения порядковых номеров следует рассматривать то, что порядковые номера сообщений, появляющиеся при последующих командах EXPUNGE, зависят от того, в каком порядке удаляются сообщения. Например, если последние 5 сообщений в почтовом ящике с 9 сообщениями стерты, сервер, удаляющий записи "снизу-вверх" пошлет 5 немаркированных откликов EXPUNGE (с номером 5), в то время как сервер, стирающий записи "сверху вниз", пошлет немаркированные отклики с номерами 9, 8, 7, 6 и 5.
Отклик EXPUNGE не должен посылаться, когда не исполняется никакая команда, или при отклике на команды FETCH, STORE или SEARCH. Это правило необходимо, чтобы предотвратить потерю синхронизации нумерации для клиента и сервера.
Информация отклика EXPUNGE должна регистрироваться клиентом.
Пример: S: * 44 EXPUNGE
Отклик FETCH
Содержимое: текст сообщения.
Отклик FETCH возвращает данные о сообщении клиенту. Данные сформированы в группы из имени элемента и его значения в скобках. Этот отклик является следствием команды FETCH или STORE, а также одностороннего решения сервера (например, об изменении флагов). В настоящее время существуют следующие информационные элементы:
BODY Форма BODYSTRUCTURE без расширения данных.
BODY[]<>
Строка, отражающая содержимое специфицированной секции. Строка должна интерпретироваться клиентом согласно транспортной кодировке, типу и субтипу тела.
Если специфицирован начальный октет, то это субстрока полного содержимого тела, начинающаяся с заданного октета. Это означает, что BODY[]<0> может быть укорочено, но BODY[] никогда не укорачивается.
Если идентификатор [CHARSET] является частью списка параметров тела секции, допустимы 8-битовые текстовые данные. Заметьте, что заголовки (спецификаторы частей HEADER, MIME или часть заголовка секции MESSAGE/RFC822), должны содержать только 7-битовые символы (применение 8-битовых символов в заголовке запрещено). Заметим также, что пустая строка в конце заголовка всегда включается в текст заголовка.
Не текстовые данные, такие как двоичные, должны передаваться закодированными в текстуальной форме, например BASE64. Чтобы получить исходные двоичные данные клиент должен декодировать полученную последовательность.
BODYSTRUCTURE - список, заключенный в скобки, который описывает [MIME-IMB],
структура тела сообщения.
Эта структура вычисляется сервером путем разбора полей заголовка [MIME-IMB], и подставления при необходимости значений по умолчанию.
Например, простое текстовое сообщение из 48 строк и 2279 октетов может иметь структуру тела: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)
Если имеется несколько частей, они выделяются вложенными скобками. Вместо типа тела в качестве первого элемента списка используется тело с иерархической структурой.
Вторым элементом списка, заключенного в скобки, является составной субтип (mixed, digest, parallel, alternative, и т.д.).
Например, сообщение из двух частей, включающее в себя текст и приложение, закодированное в BASE64, может иметь структуру тела: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED"))
Данные расширения следуют за составным субтипом. Данные расширения никогда не присылаются при доставке тела, но могут быть доставлены с помощью BODYSTRUCTURE. Данные расширения, если они присутствуют, должны иметь следующий формат:
Список параметров тела, заключенный в скобки.
Список содержит пары атрибут/значение [например, ("foo" "bar" "baz" "rag"), где "bar" представляет собой значение "foo", а "rag" является значением "baz"] как это определено в [MIME-IMB].
Размещение тела
Список, заключенный в скобки, состоящий из строки типа размещения, за которой следует список пар атрибут/значение. Имена типов размещения и атрибутов будут определены в будущих стандартах.
Язык тела
Строка или список в скобках, определяющие язык, так как это задано в [LANGUAGE-TAGS].
Любое из последующих расширений данных в данной версии протокола не определено. Такие расширения могут состоять из нуля или более NIL-строк, чисел, или вложенных списков таких данных, заключенных в скобки. Реализации клиента, которые осуществляют доставку BODYSTRUCTURE, должны быть готовы принять такие расширения данных. Реализации сервера не должны посылать такие расширения, до тех пор, пока они не войдут в новую версию протокола. Базовые поля несоставной части тела размещаются в следующем порядке:
Тип тела
Строка, описывающая имя типа содержимого, как это определено в [MIME-IMB].
Субтип тела
Строка, описывающая имя субтипа, как это определено в [MIME-IMB].
Список параметров тела, заключенный в скобки
Список пар атрибут/значение, заключенный в скобки, [например, ("foo" "bar" "baz" "rag"), где "bar" является значением "foo", а "rag" - значением "baz"], как это описано в [MIME-IMB].
Идентификатор тела
Строка, описывающая идентификатор содержимого, как это определено в [MIME-IMB].
Описание тела
Строка, предоставляющая описание содержимого, как это задано в [MIME-IMB].
Шифрование тела
Строка, предоставляющая транспортную кодировку, как это задано в [MIME-IMB].
Размер тела
Число, указывающее размер тела в октетах. Заметьте, что этот размер характеризует размер тела с учетом транспортного кодирования. Размер исходного текста может быть иным.
Тип тела MESSAGE и субтип RFC822 сразу после базовых полей содержат структуру заголовка, структуру тела и размер вложенного сообщения в строках.
Тип тела TEXT сразу после базовых полей содержат размер тела в строках. Заметьте, что этот размер отражает размер фрагмента после выполнения транспортного кодирования.
Данные расширения следуют после базовых полей и полей, перечисленных выше и зависящих от типа. Данные расширения никогда не транспортируются при передаче тела, но могут быть пересланы при доставке BODYSTRUCTURE. Данные расширения, если они присутствуют, должны быть упорядочены.
Данные расширения для несоставной части тела располагаются в следующем порядке:
MD5 тела
Строка, содержащая значение MD5 тела, как это описано в [MD5].
Размещение тела
Список, заключенный в скобки, с тем же содержимым и функциями, что и размещение тела для составной части тела.
Язык тела
Строка или список, заключенный в скобки, определяющие язык тела, как это задано в [LANGUAGE-TAGS].
Любые последующие данные расширения пока не определены в данной версии протокола.
ENVELOPE - список, заключенный в скобки, который описывает структуру заголовка (конверта) сообщения.
Он вычисляется сервером в результате разбора заголовка [RFC-822], при необходимости некоторым полям присваиваются значения по умолчанию.
Поля структуры конверта размещаются в следующем порядке: дата, subject (предмет сообщения), from (от), отправитель, reply-to (ответ на), to, cc, bcc, in-reply-to (в ответ на), и идентификатор сообщения. Поля дата, subject, in-reply-to и идентификатор сообщения являются строками. Поля from, отправитель, reply-to, to, cc и bcc являются списками адресных структур, заключенными в скобки.
Адресная структура представляет собой список, который описывает электронный почтовый адрес. Поля адресной структуры размещаются в следующем порядке: персональное имя, [SMTP] @-домен (маршрут отправителя), имя почтового ящика и имя ЭВМ.
Синтаксис группы [RFC-822] определяется специальной формой адресной структуры, в которой поле имени ЭВМ равно NIL. Если поле имени почтового ящика также равно NIL, это является концом группового маркера (двоеточие в синтаксисе RFC 822). Если поле имени почтового ящика не равно NIL, это обозначает начало группового маркера, а поле имени почтового ящика содержит имя группы.
Любое поле в конверте или адресной структуре, которое не используется, характеризуется значением NIL. Заметим, что сервер должен заполнять по умолчанию поля reply-to и sender из поля from.
| FLAGS | Список флагов, установленных для данного сообщения, заключенный в скобки. |
| INTERNALDATE | Строка, представляющая внутреннюю дату сообщения. |
| RFC822 | Эквивалент BODY[]. |
| RFC822.HEADER | Эквивалент BODY.PEEK[HEADER]. |
| RFC822.SIZE | Число, выражающее размер сообщения [RFC-822]. |
| RFC822.TEXT | Эквивалент BODY[TEXT]. |
| UID | Число, выражающее уникальный идентификатор сообщения. |
Пример: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
Отклик FLAGS
Содержимое: список флагов, заключенный в скобки.
Отклик FLAGS является результатом команды SELECT или EXAMINE. Список флагов, заключенный в скобки определяет флаги (системные флаги), которые могут использоваться для данного почтового ящика. Допускаются флаги, отличные от системных, это зависит от реализации сервера. Отклик FLAGS должен записываться клиентом.
Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
Отклик исходящего вызова OCRP (Outgoing-Call-Reply)
Сообщение Outgoing-Call-Reply (OCRP) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение OCRQ. Оно является вторым из трех сообщений, которые используются при установлении сессии в L2TP-туннеле. OCRP используется для индикации того, что LAC может попытаться послать исходящий вызов и вернуть определенные параметры, относящиеся к попытке вызова. Следующие AVP должны присутствовать в OCRP:
Тип сообщения (Message Type)
Assigned Session ID
| Следующие AVP могут присутствовать в OCRP: | Physical Channel ID |
Отклик LIST
Содержимое: атрибуты имени, иерархический разделитель, имя.
Отклик LIST посылается как результат команды LIST. Он возвращает одно имя, которое соответствует спецификации LIST. Допускается несколько откликов LIST на одну команду.
Определено четыре атрибута имени:
| \Noinferiors |
Дочерние уровни иерархии не могут иметь то же самое имя. Не существует дочерних уровней в настоящее время, и они не могут быть созданы в будущем. |
| \Noselect | Не допускается использование данного имени для именования почтового ящика, который может быть выбран. |
| \Marked |
Почтовый ящик помечен сервером как "interesting"; почтовый ящик, вероятно, содержит сообщения, которые добавлены со времени, когда почтовый ящик последний раз был выбран. |
| \Unmarked |
Почтовый ящик не содержит каких-либо дополнительных сообщений, со времени, когда почтовый ящик последний раз был выбран. |
Если сервер не может определить, является ли почтовый ящик "интересным", или, если имя имеет атрибут \Noselect, сервер не должен посылать отклики \Marked или \Unmarked. Иерархическим разделителем является символ, используемый для разграничения уровней иерархии имен почтового ящика. Клиент может использовать разделитель для формирования дочерних уровней в почтовом ящике, а также для поиска в иерархической системе имен. Все дочерние уровни верхнего уровня иерархии должны использовать один и тот же тип разделителя. Иерархический разделитель NIL означает, что никакой иерархии нет.
Имя представляет собой однозначную иерархию (слева направо) и должно быть пригодным для использования в качестве шаблона командами LIST и LSUB. Если не использован атрибут \Noselect, имя должно быть пригодно в качестве аргумента команд, типа SELECT, которые требуют ввода имени почтового ящика.
Пример: S: * LIST (\Noselect) "/" ~/Mail/foo
Отклик LSUB
Содержимое: атрибуты имени, иерархический разграничитель, имя.
Отклик LSUB является результатом команды LSUB. Он возвращает одно имя, которое соответствует спецификации LSUB. Допускается несколько откликов на одну команду LSUB. Формат данных идентичен используемому в отклике LIST.
Пример: S: * LSUB () "." #news.comp.mail.misc
Отклик NO
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик NO указывает на сообщение от сервера об операционной ошибке. В помеченной форме он отмечает неудачное завершение соответствующей команды. Непомеченная форма служит для индикации предупреждения, команда все еще может завершиться успешно. Текстовое сообщение описывает условия.
Пример: C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A223 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A223 NO COPY failed: disk is full
Отклик OK
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик OK индицирует информационное сообщение от сервера. Если оно маркировано, сообщение указывает на успешное завершение соответствующей команды. Пользователю может быть предложено текстовое информационное сообщение. Немаркированная форма указывает на чисто информационное сообщение; природа информации может быть указана в коде отклика.
Немаркированная форма используется также как один из трех видов оповещения об установлении начального соединения. Эта форма указывает, что еще не выполнена аутентификация и необходима команда LOGIN.
Пример: S: * OK IMAP4rev1 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed
Отклик PREAUTH
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик PREAUTH является всегда непомеченным и представляет собой одну из трех возможных реакций при установлении соединения. Он указывает, что для соединения уже выполнена аутентификация, и команда LOGIN не нужна.
Пример: S: * PREAUTH IMAP4rev1 server logged in as Smith
Отклик RECENT
Содержимое: отсутствует.
Отклик RECENT сообщает число сообщений с флагами \Recent. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение).
Замечание: Нельзя гарантировать, чтобы порядковые номера для последних сообщений образовывали в почтовом ящике непрерывный ряд с предыдущими. Примерами, когда складывается такая ситуация могут служить варианты: несколько клиентов, имеют один и тот же открытый почтовый ящик; или случай, когда сообщения в почтовом ящике переставлены не-IMAP приложением.
Единственным способом идентифицировать последние сообщения является рассмотрение флагов \Recent, или выполнение команды SEARCH RECENT. Информация отклика RECENT должна регистрироваться клиентом.
Пример: S: * 5 RECENT
Отклик SEARCH
Содержимое: нуль или более чисел.
Отклик SEARCH является результатом команды SEARCH или UID SEARCH. Числа относятся к тем сообщениям, которые отвечают критериям отбора. Для SEARCH это порядковые номера сообщений, а для UID SEARCH - их уникальные идентификаторы. Числа отделяются друг от друга пробелами.
Пример: S: * SEARCH 2 3 6
Отклик STATUS
Содержимое: имя, статусный список, заключенный в скобки.
Отклик STATUS является результатом команды STATUS. Он возвращает имя почтового ящика, которое соответствует спецификации STATUS, и запрашиваемую статусную информацию почтового ящика.
Пример: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
Отклик в случае, когда не исполняется никакой команды
Реализациям сервера разрешается посылать непомеченные отклики (за исключением EXPUNGE), если в это время не выполняется ни одной команды. Реализации, которые посылают такие отклики, должны учитывать соображения управления трафиком. В частности, они должны либо (1) проверить, что размер данных не превосходит транспортные возможности, или (2) использовать неблокирующую запись.
Отклик входящего вызова ICRP (Incoming-Call-Reply)
Incoming-Call-Reply (ICRP) является управляющим сообщением, посылаемым LNS к LAC в ответ на полученное сообщение ICRQ. Он является вторым из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля.
ICRP используется для индикации того, что ICRQ успешен, и для LAC, чтобы ответить на вызов, если это еще не было сделано. Оно позволяет также LNS индицировать необходимые параметры для L2TP-сессии. Следующие AVP должны присутствовать в ICRP:
Тип сообщения (Message Type)
ID, присвоенный сессии (Assigned Session ID)
Отклики сервера - отклики состояния
Статусными откликами являются OK, NO, BAD, PREAUTH и BYE. OK, NO и BAD могут быть маркированными или нет. PREAUTH и BYE - всегда не маркированы.
Статусные отклики могут включать опционный код отклика. Код отклика состоит из информации, заключенной в квадратные скобки, в форме атома. Далее может следовать пробел и аргументы. Код отклика содержит дополнительную информацию или статусные коды для программы клиента помимо условий OK/NO/BAD. Эти данные определяются, когда клиент может предпринять действия на основе этой дополнительной информации. В настоящее время определены следующие коды откликов:
| ALERT | Текстовое сообщение, содержащее специальное предупреждение, которое должно быть представлено пользователю в форме, привлекающей внимание. |
| NEWNAME | За этим откликом следует имя почтового ящика и новое имя. Команды SELECT или EXAMINE не пройдут, так как ящик места назначения более не существует из-за переименования. Это является указанием для клиента, попытаться повторить команду с новым именем почтового ящика. |
| PARSE | Текстовое сообщение, которое указывает на ошибку при разборе заголовка [RFC-822] или заголовка [MIME-IMB] сообщения в почтовом ящике. |
| PERMANENTFLAGS |
Когда за этим кодом следует в скобках список флагов, это указывает, какие из известных флагов могут быть изменены на постоянной основе. Любые флаги, которые указаны в немаркированном отклике FLAGS, но отсутствуют в списке PERMANENTFLAGS, могут быть установлены на постоянной основе. Если клиент пытается запомнить (STORE) флаг, который отсутствует в списке PERMANENTFLAGS, сервер либо отвергнет этот запрос с помощью отклика NO или запомнит состояние только до конца текущей сессии. Список PERMANENTFLAGS может также включать специальный флаг \*, который указывает, что имеется возможность создать новые ключевые слова путем записи этих флагов в почтовом ящике. |
| READ-ONLY | Почтовый ящик выбран в режиме только для чтения или доступ к нему был сменен с read-write на read-only. |
| READ-WRITE | Почтовый ящик находится в режиме read-write, или доступ к нему был сменен с read-only на read-write. |
| TRYCREATE |
Попытка выполнения APPEND или COPY оказалась неуспешной из-за того, что почтовый ящик места назначения отсутствует. Это указывает клиенту, что операция может оказаться успешной, если почтовый ящик будет сначала создан с помощью CREATE |
| UIDVALIDITY | Когда за этим кодом следует десятичное число, это указывает на значение уникального идентификатора. |
| UNSEEN | Когда за этим кодом следует десятичное число, это указывает на значение номера первого сообщения без флага \Seen. |
Дополнительные коды откликов определенные конкретным клиентом или сервером должны иметь префикс "X", если они отклоняются от рекомендаций данного документа. Реализации клиента должны игнорировать отклики, которые ими не распознаются.
Отклики сервера - размер почтового ящика
Эти отклики являются немаркированными. Они передают от сервера клиенту информацию об изменении размера почтового ящика. Число, которое следует за символом "*" определяет количество сообщений.
Отклики сервера - сообщения о состоянии сервера и почтового ящика
Эти отклики всегда не маркированы. Они служат для передачи статусной информации сервера и почтового ящика клиенту. Большинство этих откликов являются результатом команд, носящих то же имя.
Отклики сервера - статусное сообщение
Эти отклики являются немаркированными. Они несут информацию о том, как сообщения доставляются от сервера к клиентам, и возникают как результат работы одноименных команд. Сразу за символом "*" следует число, которое является порядковым номером сообщения.
Отклики сервера - запрос продолжения команды
Отклик на запрос продолжения команды вместо метки выделяется символом "+". Эта форма отклика указывает на то, что сервер готов принять продолжение команды от клиента. Остальная часть этого отклика имеет текстовую форму.
Этот отклик используется командой AUTHORIZATION, для того чтобы передать данные от сервера клиенту, и запросить дополнительные данные у клиента. Этот отклик применяется также, если аргументом какой-то команды является литерал.
Клиенту не позволено посылать литеральные октеты, если только сервер в явной форме не запросил их. Это позволяет серверу обрабатывать команды и отвергать ошибки строчка за строчкой. Остальная часть команды, включая CRLF, завершающие команду, следует за октетами литерала. Если имеются какие-либо дополнительные аргументы команды, за литеральными октетами следует пробел, после чего передаются аргументы.
Пример: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"
Отсутствие следующего заголовка
Код 59 в поле следующий заголовок IPv6 заголовка или любой другой заголовок расширения указывает, что за этим заголовком ничего не следует. Если поле длина данных заголовка IPv6 указывает на присутствие октетов после конца заголовка, содержащего код 59 в поле следующий заголовок, эти октеты должны быть проигнорированы и переданы без изменений при переадресации пакета.
Outgoing-Call-Connected (OCCN)
Сообщение Outgoing-Call-Connected (OCCN) является управляющим сообщением, посылаемым от LAC к LNS, следом за OCRP, и после того как исходящий вызов завершен. Это завершающее сообщение из трех, используемых при установлении сессии в пределах L2TP-туннеля.
OCCN используется для индикации того, что результат запрошенного исходящего вызова положителен. Оно также предоставляет LNS информацию об определенных параметрах, полученных после реализации вызова. Следующие AVP должны присутствовать в OCCN:
Тип сообщения (Message Type)
Скорость обмена ((Tx) Connect Speed)
Тип кадрового обмена (Framing Type)
Следующие AVP могут присутствовать в OCCN:
Скорость обмена (Rx Connect Speed)
Необходима нумерация (Sequencing Required)
Пакетные I/O интерфейсы RSVP
Реализация RSVP нуждается в следующей поддержке со стороны систем ввода/вывода пакетов и со стороны механизма переадресации узла. Неизбирательный режим приема сообщений RSVP
Пакеты, полученные для IP-протокола (код 46) но не адресованные узлу, должны быть переправлены программе RSVP для последующей обработки. Сообщения RSVP переправляемые таким образом включают сообщения Path, PathTear и ResvConf. Эти типы сообщений несут в себе IP-опцию оповещение маршрутизатора (Router Alert), которая может быть использована для выделения этих пакетов в высокоскоростном канале переадресации. В качестве альтернативы узел может перехватывать все пакеты с кодом протокола 46.
В маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами идентификация интерфейса (реального и виртуального), через который получено заданное сообщение, также как IP-адрес источника и TTL, с которым оно получено, должна быть также доступна для процесса RSVP. Спецификация выходного канала
RSVP должен уметь обеспечить посылку дейтограммы через специальный выходной интерфейс (реальный или виртуальный) в обход обычного механизма маршрутизации. Виртуальным каналом может быть, например, мультикастный туннель. Спецификация адреса источника и TTL
RSVP должен быть способен специфицировать IP-адрес отправителя и TTL, которые могут использоваться при посылке сообщений Path. Оповещение маршрутизатора
RSVP должен быть способен вызвать посылку сообщения Path, PathTear и ResvConf с опцией оповещения маршрутизатора (Router Alert).
Переадресация кадров PPP
Когда туннель сформирован, PPP-кадры от удаленной системы, получаемые LAC, освобождаются от CRC, канальных заголовков, и т.д., инкапсулированных в L2TP, и переадресуются через соответствующий туннель. LNS получает L2TP-пакет, и обрабатывает инкапсулированный PPP-кадр, как если бы он был получен через локальный интерфейс PPP.
Отправитель сообщения, ассоциированный с определенной сессией и туннелем, помещает ID сессии и туннеля (специфицированные партнером) в соответствующие поля заголовка всех исходящих сообщений. Таким способом, PPP-кадры мультиплексируются и демультиплексируются через общий туннель для данной пары LNS-LAC. Для заданной пары LNS-LAC может быть реализовано несколько туннелей, а для любого туннеля несколько сессий.
Значение 0 для ID-сессии и ID-туннеля является зарезервированным и не должно использоваться в качестве ID-сессии или ID-туннеля. Для случаев, когда ID-сессии еще не присвоен партнером (т.e., в процессе установления новой сессии или туннеля), поле ID-сессии должно содержать 0, а для идентификации сессии должна использоваться AVP ID-сессии сообщения. Аналогично, для случаев, когда ID-туннеля еще не присвоен партнером, ID-туннеля должен быть присвоен 0, а для идентификации туннеля должна использоваться AVP ID-туннеля.
Почтовый протокол POP
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
В некоторых небольших узлах Интернет бывает непрактично поддерживать систему передачи сообщений (MTS - Message Transport System). Рабочая станция может не иметь достаточных ресурсов для обеспечения непрерывной работы SMTP-сервера [RFC-821]. Для “домашних ЭВМ” слишком дорого поддерживать связь с Интернет круглые сутки.
Но доступ к электронной почте необходим как для таких малых узлов, так и индивидуальных ЭВМ. Для решения этой проблемы разработан протокол POP3 (Post Office Protocol - Version 3, STD: 53. M. Rose, RFC-1939). Этот протокол обеспечивает доступ узла к базовому почтовому серверу.
POP3 не ставит целью предоставление широкого списка манипуляций с почтой, он лишь получает и стирает почтовые сообщения. Более продвинутый и сложный протокол IMAP4 обсуждается в RFC-2060 (порт 143). Об аутентификации в POP3 можно прочесть в документе RFC-1734.
В дальнейшем ЭВМ-клиентом будет называться машина, пользующаяся услугами POP3, а ЭВМ-сервером - сторона, предлагающая услуги POP3.
Когда пользователь ЭВМ-клиента хочет послать сообщение, он устанавливает SMTP связь с почтовым сервером непосредственно и посылает все, что нужно через него. При этом ЭВМ POP3-сервер не обязательно является почтовым сервером.
В исходный момент ЭВМ POP3-сервер прослушивает TCP-порт 110. Если ЭВМ-клиент хочет воспользоваться услугами POP3-сервера, то устанавливает с ним TCP связь. По установлении связи POP3-сервер посылает клиенту уведомление (например, +OK POP3 server ready) и сессия переходит в фазу авторизации (см. также RFC-1734, -1957). После этого может производиться обмен командами и откликами.
Команды POP3 состоят из ключевых слов (3-4 символа), за которыми могут следовать аргументы. Каждая команда завершается парой символов CRLF. Как ключевые слова, так и аргументы могут содержать только печатаемые ASCII-символы. В качестве разделителя используются символы пробела. Каждый аргумент может содержать до 40 символов.
Сигнал отклика в POP3 содержит индикатор состояния и ключевое слово, за которым может следовать дополнительная информация.
Отклик также завершается кодовой последовательностью CRLF. Длина отклика не превышает 512 символов, включая CRLF. Существует два индикатора состояния: положительный - "+OK" и отрицательный "-ERR" (все символы прописные).
Отклики на некоторые команды могут содержать несколько строк. В этом случае последняя строка содержит код завершения 046 ("."), за которым следует CRLF.
На практике многострочные отклики для исключения имитации завершаются последовательностью CRLF.CRLF.
В процессе авторизации клиент должен представить себя серверу, передав имя и пароль (возможен вариант посылки команды APOP). Если авторизация успешно завершена, сессия переходит в состояние транзакции (TRANSACTION). При получении от клиента команды QUIT сессия переходит в состояние UPDATE, при этом все ресурсы освобождаются и TCP связь разрывается.
На синтаксически неузнанные и неверные команды, сервер реагирует, посылая отрицательный индикатор состояния.
POP3 сервер может быть снабжен таймером пассивного состояния (10 мин.), который осуществляет автоматическое прерывание сессии. Приход любой команды со стороны клиента сбрасывает этот таймер в нуль.
Сервер нумерует все передаваемые сообщения из своего почтового ящика и определяет их длину. Положительный отклик начинается с +OK, за ним следует пробел, номер сообщения, еще один пробел и длина сообщения в октетах. Завершается отклик последовательностью CRLF. Переданные сообщения удаляются из почтового ящика сервера. Все сообщения, передаваемые во время сессии POP3 должны следовать рекомендациям формата Интернет сообщений [RFC822].
В состоянии транзакции клиент может посылать серверу последовательность POP3 команд, на каждую из которых сервер должен послать отклик. Далее следует краткое описание команд, используемых в состоянии транзакция.
LIST [сообщение]
Аргументы: номер сообщения (опционно), который не может относиться к сообщению, помеченному как удаленное. Команда может быть выдана только в режиме TRANSACTION.
При наличии аргумента сервер выдает положительный отклик, содержащий информационную строку сообщения. Такая строка называется скэн-листингом сообщения (scan listing). scan listing состоит из номера сообщения, за которым следует пробел и число октетов в сообщении. Сообщения, помеченные как удаленные, не пересылаются. Примером отрицательного отклика может служить: -ERR no such message.
Примеры использования команды LIST:
Клиент выдает команду: LIST
Сервер откликается: +OK 2 messages (320 octets)
Сервер: 1 120
Сервер: 2 200
Сервер: .
...
Клиент: LIST 2
Сервер: +OK 2 200
...
К: LIST 3
С: -ERR no such message, only 2 messages in maildrop
Здесь и далее символом К обозначается клиент, а символом С - сервер.
STAT - аргументов не использует, возможный отклик +OK nn mm, где nn - номер сообщения, а mm - его длина в байтах. Пример использования:
К: STAT
С: +OK 2 320
QUIT - аргументов не использует, возможный отклик +OK.
Сервер POP3 удаляет все сообщения, помеченные как удаленные из почтового ящика, посылает соответствующий отклик и разрывает TCP связь. Пример:
К: QUIT
С: +OK dewey POP3 server signing off.
RETR msg (msg - номер сообщения)
Если POP3-сервер выдал положительный отклик, то за начальным +OK следует сообщение с номером, указанным в аргументе. Отрицательный отклик имеет вид -ERR no such message.
Пример использования команды:
К: RETR 1
С: +OK 120 octets
С:
С: .
DELE msg (msg - номер сообщения)
Сервер POP3 помечает сообщение как удаленное. Любая ссылка на это сообщение в будущем вызовет ошибку. При этом само сообщение не удаляется пока сессия не войдет в режим UPDATE.
Пример использования команды:
К: DELE 1
С: +OK message 1 deleted
...
К: DELE 2
С: -ERR message 2 already deleted
NOOP (не использует каких-либо аргументов). При реализации этой команды сервер не делает ничего, лишь посылает положительный отклик.
RSET (не использует каких-либо аргументов)
Если какие-либо сообщения помечены как удаленные, сервер POP3 удаляет эту пометку и возвращает положительный отклик.
Например:
К: RSET
С: +OK maildrop has 2 messages (320 octets)
Если сессия завершается не по команде клиента, то перехода в состояние UPDATE не производится, а сообщения не удаляются из почтового ящика. Далее следует описание команд, используемых в состоянии UPDATE.
Ряд команд не входят в перечень обязательных (являются опционными).
TOP msg n, где msg - номер сообщения, а n - число строк (используется только в режиме TRANSACTION).
При положительном отклике на команду TOP сервер посылает заголовки сообщений и вслед за ними n строк их текста. Если n больше числа строк в сообщении, посылается все сообщение.
UIDL [msg], где msg - номер сообщения является опционным (Unique-ID Listing).
Если сервер выдаст положительный отклик, будет выдана строка, содержащая информацию о данном сообщении. Эта строка называется уникальным идентификатором сообщения ("unique-id listing"). При отсутствии аргумента аналогичная информация выдается для каждого из сообщений в почтовом ящике. Уникальный идентификатор сообщения состоит из 1-70 символов в диапазоне от 0x21 до 0x7E. Сообщения в почтовом ящике должны характеризоваться различными идентификаторами. Пример использования команды:
К: UIDL
С: +OK
С: 1 whqtswO00WBw418f9t5JxYwZ
С: 2 QhdPYR:00WBw1Ph7x7
USER name, где name - характеризует почтовый ящик сервера.
Команда используется на фазе авторизации или после неудачного завершения команд USER или PASS. При авторизации клиент должен сначала послать команду USER и лишь после получения положительного отклика команду PASS. Команда может вызвать следующие отклики:
+OK name is a valid mailbox
-ERR never heard of mailbox name
Примеры использования команды USER:
К: USER frated
С: -ERR sorry, no mailbox for frated here
...
К: USER mrose
С: +OK mrose is a real hoopy frood
PASS string (string - пароль для доступа к почтовому серверу)
Команда работает в режиме авторизации сразу после команды USER. Когда клиент выдает команду PASS, сервер использует аргументы команд USER и PASS для определения доступа клиента к почтовому ящику.
На команду PASS возможны следующие отклики:
+OK maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop
Пример диалога при использовании команды PASS:
К: USER mrose
С: +OK mrose is a real hoopy frood
К: PASS secret
С: -ERR maildrop already locked
...
К: USER mrose
С: +OK mrose is a real hoopy frood
К: PASS secret
С: +OK mrose's maildrop has 2 messages (320 octets)
APOP name digest, где name - идентификатор почтового ящика, а digest - дайджест сообщения - MD5 (RFC-1828). Команда используется только на стадии авторизации.
Обычно любая сессия начинается с обмена USER/PASS. Но так как в некоторых случаях подключения к серверу POP3 может осуществляться достаточно часто, возрастает риск перехвата пароля. Альтернативным методом авторизации является использование команды APOP. Сервер, который поддерживает применение команды APOP, добавляет временную метку в свое стартовое уведомление. Синтаксис временной метки соответствует формату идентификаторов сообщений, описанному в [RFC822] и должны быть уникальными для всех заголовков уведомлений. Так для UNIX-приложений синтаксис временной метки должен иметь вид:
где `process-ID' представляет собой десятичное значение PID процесса, clock - десятичное показание системных часов, а hostname - полное имя домена, где размещен сервер POP3.
Клиент POP3 фиксирует временную метку и выдает команду APOP. Параметр `name' семантически идентичен параметру `name' команды USER. Параметр `digest' вычисляется с использованием алгоритма MD5 [RFC1321] для строки, состоящей из временной метки (включая угловые скобки) за которой следует строка пароля, которая известна только клиенту и серверу. Параметр `digest' содержит 16 октетов, которые пересылаются в шестнадцатеричном формате с использованием строчных ASCII символов. Сервер, получив команду APOP, проверяет принятый дайджест и если он корректен, посылает положительный отклик клиенту. Сессия при этом переходит в состояние транзакции. В противном случае посылается отрицательный отклик и состояние сессии не изменяется.С целью обеспечения безопасности для каждого конкретного пользователя и сервера должен использоваться либо метод доступа USER/PASS, либо APOP, но не в коем случае оба метода попеременно.
Сервер перед закрытием канала по команде QUIT должен удалить из почтового ящика все сообщения, которые были перенесены с помощью команд RETR.
Предполагается, что все сообщения, передаваемые в ходе сессии POP3, имеют текстовый формат Интернет в соответствии с документом [RFC822].
Политика в области трафика и узлы с не интегрированными услугами
Некоторые уровни QoS могут требовать определенной политики в управлении трафиком в некоторых или всех перечисленных ниже случаях: Краевые точки сети.Точки объединения данных от многих отправителей.Точки ветвления, где трафик в различных ветвях может требовать различных уровней резервирования.
RSVP знает, где такие точки находятся, и должен обеспечивать этими данными механизм управления трафиком. С другой стороны, RSVP не интерпретирует информацию в flowspec и, следовательно, не знает, использованы ли рекомендации управления в каждом конкретном случае.
Процесс RSVP передает управлению трафиком специальный флаг политики для каждой из трех указанных выше ситуаций. E_Police_Flag – управление входом
Этот флаг устанавливается для первого узла RSVP, который реализует управление трафиком. Например, ЭВМ-отправители должны поддерживать RSVP, но многие из них не поддерживают управление трафиком. В этом случае флаг E_Police_Flag в ЭВМ-отправителе должен быть равен нулю, флаг устанавливается равным 1, когда достигнута первая ЭВМ, поддерживающая управление трафиком. Это контролируется флагом E_Police в объектах SESSION. M_Police_Flag – управление объединением
Этот флаг должен быть установлен для резервирования, использующего стили WF или SE, когда объединяются потоки более чем одного отправителя. B_Police_Flag –управление ветвлением
Этот флаг должен быть установлен, когда инсталлированная flowspec меньше или сравнима с FLOWSPEC какого-либо другого интерфейса для того же самого FILTER_SPEC и SESSION.
RSVP должен также проверять наличие вдоль пути узлов, не поддерживающих RSVP, и переправлять эту информацию управлению трафиком. На основании этого флага и другой сопутствующей информации система контроля трафиком может обнаружить узлы, которые не способны обеспечить управление QoS. Эта информация передается получателям в спецификации Adspecs [RFC 2210].
При обычной IP-переадресации, RSVP может обнаружить узлы без поддержки RSVP путем сравнения значения IP TTL, с которым послано сообщение Path, с полученным TTL. Для этой цели TTL помещается в общий заголовок. Однако, TTL не всегда является надежным индикатором узлов без поддержки RSVP, и для этих целей иногда используются другие средства. Например, если маршрутный протокол использует туннели с IP-инкапсуляцией, этот протокол должен проинформировать RSVP о наличии узлов, лишенных поддержки RSVP. В отсутствии автоматических механизмов осуществляется ручная конфигурация.
Порядок заголовков расширения
Когда используется более одного заголовков расширения в одном пакете, рекомендуется помещать их в следующем порядке:
IPv6 заголовок
Заголовок опций hop-by-hop
Заголовок опций места назначения (destination options header, (1) )
Заголовок маршрутизации
Заголовок фрагмента
Заголовок authentication (2)
Заголовок безопасных вложений (encapsulating security payload, (2) )
Заголовок опций места назначения (destination options header (3) )
Заголовок верхнего уровня.
(1) для опций, которые должны обрабатываться по адресу, указанному в поле IPv6 destination address и во всех узлах, перечисленных в заголовке маршрутизации.
(2) дополнительные рекомендации относительно порядка заголовков authentication и encapsulating security payload приведены в RFC-1827.
(3) для опций, которые должны обрабатываться при достижении пакетом конечной точки маршрута.
Каждый заголовок расширения должен встречаться не более одного раза, исключение представляет собой заголовок опций места назначения, который должен быть представлен дважды (один раз перед заголовком маршрутизации и второй раз перед заголовком верхнего уровня).
Если заголовок верхнего уровня представляет собой еще один IPv6 заголовок (в случае туннелирования IPv6 или инкапсуляции в IPv6), за ним может следовать его собственный заголовок расширения.
Узлы IPv6 должны принимать и пытаться обработать заголовки расширения в любом порядке, встречающиеся любое число раз в пределах одного пакета, за исключением заголовка опций типа hop-by-hop, который может появляться только непосредственно за IPv6 заголовком.
Посылка сообщений RSVP
Сообщения RSVP посылаются от узла к узлу между RSVP-маршрутизаторами, поддерживающими этот протокол, в виде IP-дейтограмм с кодом протокола 46. IP-дейтограммы предназначены также для использования между оконечными системами и первыми/последними маршрутизаторами.
Сообщения Path, PathTear и ResvConf должны посылаться с опцией Router Alert IP [RFC-2113] в их IP-заголовках.
По прибытии RSVP-сообщения M, которое меняет статус, узел должен немедленно послать сообщение о модификации состояния. Однако это не должно привести к посылке сообщения через интерфейс, откуда пришло M (что может случиться, если приложение запустит процедуру обновления состояний для текущей сессии). Это правило предотвращает лавину пакетов в сетях с широковещательной рассылкой.
Каждое RSVP-сообщение должно пересылаться только в одной IP-дейтограмме. Если оно превосходит MTU, такая дейтограмма будет фрагментирована. Восстановление сообщения будет произведено узлом-получателем. Это имеет несколько следствий: Одиночное RSVP-сообщение не должно превосходить максимального размера IP-дейтограммы, примерно 64K байт (на практике значительно меньше!).Перегруженные сетевые области, которые не поддерживают RSVP, могут потерять отдельные фрагменты, а это приведет к потере всего сообщения.
RSVP использует свой механизм периодического обновления для предотвращения влияния случайной потери отдельных пакетов. При перегрузке сети, однако, существенные потери RSVP-сообщений могут вызвать серьезные нарушения при резервировании сетевых ресурсов. Для контроля задержек, связанных с обслуживанием очереди, и влияния потерь RSVP пакетов, маршрутизаторы должны быть сконфигурированы так, чтобы обеспечивать для данных целей приоритетное обслуживание. Если RSVP-пакеты идут через область сети, где вероятность потери значительна, следует увеличить значение таймаутов.
Некоторые мультикастные протоколы маршрутизации обеспечивают туннели, которые организуют IP-инкапсуляцию мультикастных пакетов и их транспортировку через маршрутизаторы, которые не поддерживают мультикастную маршрутизацию. RSVP может работать через такие мультикастные туннели следующим образом: Когда узел N направляет сообщение Path выходному логическому интерфейсу L, он включает в сообщение дескриптор логического интерфейса LIH (logical interface handle). Значение LIH содержится в объекте RSVP_HOP.Следующий узел N' запоминает значение LIH в своем состоянии прохода.Когда N' посылает сообщение Resv узлу N, он включает в него значение LIH из состояния прохода (содержится в объекте RSVP_HOP).Когда сообщение Resv прибывает в N, его значение LIH выдает информацию, необходимую для осуществления резервирования в определенном логическом интерфейсе. Заметим, что узел N создает и интерпретирует LIH, которое совершенно не доступно для узла N'.
Потоки данных
RSVP определяет сессию как поток данных с определенным местом назначения и заданным транспортным протоколом. Каждая сессия является совершенно независимой.
Сессия RSVP описывается тремя параметрами: DestAddress, ProtocolId [, DstPort]. DestAddress – IP-адрес места назначения информационных пакетов (уникаст или мультикаст). ProtocolId – идентификатор IP протокола. Опционный параметр DstPort – обобщенный порт места назначения, т.е., еще одна точка демультиплексирования на транспортном или прикладном уровне. DstPort может быть определено полем порта места назначения UDP/TCP.
Заметим, что, строго говоря, не обязательно включать в описание сессии DstPort, когда DestAddress является мультикастным, так как различные сессии могут всегда иметь различные мультикаст-адреса. Однако, DstPort необходим для того, чтобы разрешить более одной уникаст-сессии для одной и той же ЭВМ-получателя.
Для уникастной передачи может быть один получатель, но много отправителей; RSVP может выполнить резервирование для передачи много_точек -> одна_точка.
Предопределенные мультикаст-адреса
Приведенные ниже мультикаст-адреса являются зарезервированными (предопределенными):
ff00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0
Перечисленные выше мультикаст-адреса зарезервированы и не будут присваиваться каким-либо мультикаст-группам.
Адреса для обращения ко всем узлам:
FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1
Приведенные выше адреса идентифицируют группу, включающую в себя все IPv6 узлы в пределах группы 1 (локальные узлы) или 2 (локально связанные узлы).
Адреса всех маршрутизаторов:
FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
Приведенные выше мультикаст-адреса идентифицируют группу всех IPv6 маршрутизаторов в пределах области 1 (локальные узлы) или 2 (связанные локально узлы).
DHCP server/relay-agent: FF02:0:0:0:0:0:0:C
Приведенные выше мультикастинг-адреса идентифицируют группу всех IPv6 DHCP серверов и транзитных агентов в пределах области (scope) 2 (локальный канал).
Адрес активного узла (solicited-node): FF02:0:0:0:0:1:xxxx:xxxx
Приведенный выше мультикаст-адрес вычислен как функция уникастного и эникастного адресов узла. Мультикаст-адрес активного узла (solicited-node) сформирован из младших 32 бит адреса (уникастного или эникастного) добавлением 96 битного префикса FF02:0:0:0:0:1. В результате получен мультикастинг адрес, охватывающий интервал:
ff02:0:0:0:0:1:0000:0000
до
FF02:0:0:0:0:1:FFFF:FFFF
Например, код мультикаст-адреса активного узла (solicited node), соответствующий IPv6 адресу 4037::01:800:200E:8C6C, равен FF02::1:200E:8C6C. IPv6 адреса, которые отличаются только старшими разрядами, например, из-за множественных старших префиксов, соответствующих разным провайдерам, будут совпадать с адресом активного узла, что сокращает число мультикаст-групп, к которым узел должен присоединиться.
