RFC 2659 Security Extensions For HTML

Network Working Group                                    E. Rescorla
Requests for Comments: 2659                               RTFM, Inc.
Category: Experimental                                  A. Schiffman
                                                Terisa Systems, Inc.
                                                         August 1999

 

Безопасность HTML (расширение)

Security Extensions For HTML

PDF

Статус документа

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

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

Тезисы

Этот документ описывает синтаксис для вложенных параметров согласования S-HTTP в документах HTML. Расширение S-HTTP, описанное в RFC 2660, содержит концептуальное описание заголовков согласования, отражающие потенциальные предпочтения получателя сообщения как криптографическое расширение, которое должно быть применено к сообщению. Документ описывает синтаксис связывания этих параметров согласования с “якорями” HTML.

1. Введение

2. Атрибуты Anchor

Определим три новых атрибута “якорей” (anchor) и передачи форм (form submission):

DN — отличительное имя доверителя (principal), для которого должен шифроваться запрос при разыменовании (dereferencing) “якоря” в url. Это требование не включено в спецификацию, но отказ от его выполнения может привести к тому, что клиент не сможет определить DN и, следовательно, не сможет выполнить шифрование. Имя должно указываться в формате RFC1485 с использованием соглашений SGML.

NONCE — строка произвольного формата (в “кавычках” SGML), которая включается в заголовок SHTTP-Nonce: (после удаления “кавычек” SGML) при разыменовании “якоря”.

CRYPTOPTS — информация о криптографических опциях в соответствии с [SHTTP] (в частности, <cryptopt-list>).

2.1. Элемент CERTS

Определяется новый элемент HTML CERTS, который передает группу сертификатов (не обязательно связанных), обеспечиваемых в качестве дополнительной информации (advisory data). Содержимое этого элемента не предназначено для вывода на экран пользователя. Могут использоваться группы сертификатов для PEM или PKCS-7. Такие сертификаты передаются в документах HTML для удобства получателя, который при отсутствии данных может оказаться неспособен найти сертификаты (цепочки), соответствующие DN, указанному в ссылке (anchor).

Формат элемента должен быть таким же, как для строки заголовка Certificate-Info [SHTTP]; единственное отличие состоит в том, что должен обеспечиваться спецификатор <Cert-Fmt> как атрибут FMT в теге.

Допускается использование множества элементов CERTS; предполагается, что сами элементы CERTS включаются в заголовок (HEAD) документа HTML (чтобы данные из этого элемента не выводились на экран браузерами HTML, которые не поддерживают S-HTTP).

2.2. Элемент CRYPTOPTS

Опции Cryptopts также могут включаться в элемент и указываться в “якоре” по имени. Атрибут NAME задает имя, которым этот элемент может быть указан в атрибуте CRYPTOPTS “якоря”. Имена должны иметь в начале по крайней мере один символ #.

2.3. Пример HTML

Ниже приведен пример криптографических данных, вложенных в “якорь” и содержащих группу сертификатов. Отметим использование синтаксиса SGML для записи данных.

        <CERTS FMT=PKCS-7>
        MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqhkiG9w0BBwEAAKCAM
        IIBrTCCAUkCAgC2MA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwH
        gYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc
        29uYSBDZXJ0aWZpY2F0ZTAeFw05NDA0MDkwMDUwMzdaFw05NDA4MDIxODM4N
        TdaMGcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0e
        SwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEYMBYGA1UEA
        xMPU2V0ZWMgQXN0cm9ub215MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMy8Q
        cW7RMrB4sTdQ8Nmb2DFmJmkWn+el+NdeamIDElX/qw9mIQu4xNj1FfepfJNx
        zPvA0OtMKhy6+bkrlyMEU8CAwEAATANBgkqhkiG9w0BAQIFAANPAAYn7jDgi
        rhiIL4wnP8nGzUisGSpsFsF4/7z2P2wqne6Qk8Cg/Dstu3RyaN78vAMGP8d8
        2H5+Ndfhi2mRp4YHiGHz0HlK6VbPfnyvS2wdjCCAccwggFRAgUCQAAAFDANB
        gkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhd
        GEgU2VjdXJpdHksIEluYy4xLjAsBgNVBAsTJUxvdyBBc3N1cmFuY2UgQ2Vyd
        GlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQwMTA3MDAwMDAwWhcNOTYwMTA3M
        jM1OTU5WjBNMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2Vjd
        XJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydGlmaWNhdGUwaTANB
        gkqhkiG9w0BAQEFAANYADBVAk4GqghQDa9Xi/2zAdYEqJVIcYhlLN1FpI9tX
        Q1m6zZ39PYXK8Uhoj0Es7kWRv8hC04vqkOKwndWbzVtvoHQOmP8nOkkuBi+A
        QvgFoRcgOUCAwEAATANBgkqhkiG9w0BAQIFAANhAD/5Uo7xDdp49oZm9GoNc
        PhZcW1e+nojLvHXWAU/CBkwfcR+FSf4hQ5eFu1AjYv6Wqf430Xe9Et5+jgnM
        Tiq4LnwgTdA8xQX4elJz9QzQobkE3XVOjVAtCFcmiin80RB8AAAMYAAAAAAA
        AAAAA==
        </CERTS>
        <A name=foobar
        DN="CN=Setec Astronomy, OU=Persona Certificate,
            O=&quot;RSA Data Security, Inc.&quot;, C=US"
        CRYPTOPTS="SHTTP-Privacy-Enhancements: recv-refused=encrypt;
        SHTTP-Signature-Algorithms: recv-required=NIST-DSS"
        HREF="shttp://research.nsa.gov/skipjack-holes.html">
        Don't read this. </A>

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

Весь документ посвящен вопросам безопасности.

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

Eric Rescorla

RTFM, Inc.

30 Newell Road, #16

East Palo Alto, CA 94303

Phone: (650) 328-8631

EMail: ekr@rtfm.com

 

Allan M. Schiffman

SPYRUS/Terisa

5303 Betsy Ross Drive

Santa Clara, CA 95054

Phone: (408) 327-1901

EMail: ams@terisa.com


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

Николай Малых

nmalykh@gmail.com

5. Литература

[SHTTP] Rescorla, E. and A. Schiffman, «The Secure HyperText Transfer Protocol», RFC 2660, August 1999.

6. Полное заявление авторских прав

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Подтверждение

Финансирование функций RFC Editor обеспечивается Internet Society.




RFC 2644 Changing the Default for Directed Broadcasts in Routers

Network Working Group                                       D. Senie
Request for Comments: 2644                    Amaranth Networks Inc.
Updates: 1812                                           August 1999
BCP: 34
Category: Best Current Practice

Смена принятого по умолчанию поведения маршрутизаторов по отношению к пакетам Directed Broadcast

Changing the Default for Directed Broadcasts in Routers

PDF

Статус документа

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

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Введение

В требованиях к маршрутизаторам [1] указано, что эти устройства должны принимать и пересылать широковещательный трафик directed broadcast1. В этом же документе указано, что маршрутизаторы должны иметь опцию, позволяющую запретить эту функцию, и по умолчанию функция приема и пересылки directed broadcast должна быть включена. Однако поддержка пересылки таких пакетов обеспечивает возможность организации эффективных атак на другие сети.

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

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119.

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

Разрушительные атаки на службы2 привели к необходимости разработки системы фильтрации входящего трафика — Ingress Filtering [2]. Фильтрация на входе сейчас используется многими сетевыми операторами, а также в корпоративных сетях для предотвращения DOS-атак.

Недавние Smurf-атаки [3] были направлены против сетей, которые поддерживают directed broadcast из внешних сетей. Поддержка directed broadcast делала такие сети «усилителями» Smurf-атак.

Реализация ingress-фильтров является наилучшим решением проблемы, однако ограничение использования directed broadcast также сыграет позитивную роль.

Провайдеры и корпоративные пользователи хотят оградить свои сети от пакетов directed broadcast, приходящих из внешних сетей.

Mobile IP [4] предлагает использовать directed broadcast в мобильных узлах для динамического детектирования сетей. Хотя такая функция применяется в некоторых реализациях, польза ее совершенно не очевидна. В работе [5] предложены другие способы решения таких задач. Имеет смысл рассмотреть вопрос об отмене использования directed broadcast в Mobile IP, пока рассматривается вопрос о принятии стандарта.

3. Рекомендации

Внести в документ [1] следующие изменения:

Параграф 4.2.2.11 (d) заменить на:

(d) { <Network-prefix>, -1 }

Directed Broadcast – широковещательный адрес для сети с указанным префиксом. Недопустимо использование таких адресов в поле отправителя. Маршрутизатор может генерировать пакеты Network Directed Broadcast. Маршрутизатор может иметь конфигурационную опцию, разрешающую прием пакетов directed broadcast, однако эта опция должна быть отключена по умолчанию и, таким образом, для маршрутизаторов недопустимо принимать пакеты Network Directed Broadcast, пока это на задано явно конечным пользователем.

Второй абзац параграфа 5.3.5.2 заменить на:

Маршрутизатор может иметь опцию, разрешающую прием широковещательных пакетов для заданной префиксом сети (network-prefix-directed broadcast) на уровне интерфейсов и может иметь опцию для разрешения пересылки таких пакетов. Эти опции по умолчанию должны быть отключены, чтобы блокировать прием и передачу пакетов network-prefix-directed broadcast.

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

Задача этого документа состоит в снижении эффективности некоторых типов атак на службы (DoS).

5. Литература

[1] Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.

[2] Ferguson, P. and D. Senie, «Ingress Filtering», RFC 2267, January 1998.

[3] Публикация Craig Huegen на сайте http://www.quadrunner.com/~chuegen/smurf.txt и документ CERT http://www.cert.org/advisories/CA-98.01.smurf.html

[4] Perkins, C., «IP Mobility Support», RFC 2002, October 1996.

[5] P. Calhoun, C. Perkins, «Mobile IP Dynamic Home Address Allocation Extensions», Work in Progress5.

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

Автор благодарит Брэндона Росса (Brandon Ross) из Mindspring и Гэбриела Монтенегро (Gabriel Montenegro) из Sun за их вклад в работу.

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

Daniel Senie

Amaranth Networks Inc.

324 Still River Road

Bolton, MA 01740

Phone: (978) 779-6813

EMail: dts@senie.com


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

Николай Малых

nmalykh@protocols.ru

8. Полное заявление авторских прав

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Directed Broadcast — широковещательный пакет, направленный в сеть с заданным префиксом (номер сети). Прим. перев.

2 Denial of Service — DOS. Прим. перев.

5Этот документ опубликован как RFC 2794 — Mobile IP Network Access Identifier Extension for IPv4. Прим. перев.




RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations

Network Working Group                                   P. Srisuresh
Request for Comments: 2663                               M. Holdrege
Category: Informational                          Lucent Technologies
                                                         August 1999

Транслятор сетевых адресов IP (NAT) — терминология и рассмотрение

IP Network Address Translator (NAT) Terminology and Considerations

PDF

Статус документа

Этот документ содержит информацию для сообщества Internet и не определяет каких-либо стандартов. Документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

Предисловие

Мотивом создания документа послужило желание внести ясность в терминологию, используемую в связи с трансляторами сетевых адресов (Network Address Translator). Сам термин «транслятор сетевых адресов» может относиться к разным субъектам в зависимости от контекста. Целью этого документа является определение различных вариантов NAT1 и стандартизация значений применяемых терминов.

Указанные в списке авторы являются редакторами этого документа и обязаны отметить существенный вклад членов рабочей группы. Значительные фрагменты документа под названием IP Network Address Translator (NAT) были использованы почти дословно и обеспечили стартовую базу для этого документа. Редакторы рады поблагодарить авторов этого документа Pyda Srisuresh и Kjeld Egevang. Редакторы рады поблагодарить Praveen Akkiraju за его вклад в описание сценариев развертывания NAT. Редакторы также выражают свою признательность членам IESG Scott Bradner, Vern Paxson и Thomas Narten за детальный анализ документа и улучшение текста.

Тезисы

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

1. Введение и обзор

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

Трансляция адресов позволяет (во многих случаях, за исключением отмеченных в разделах 8 и 9) хостам частных сетей взаимодействовать с адресатами из внешних сетей и наоборот. Имеется множество вариантов NAT и связанных с ними терминов. Этот документ пытается определить терминологию, используемую для идентификации разных вариантов NAT. Рассматриваются также другие вопросы, относящиеся к устройствам NAT в целом.

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

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

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

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

2. Терминология и используемые концепции

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

2.1. Область адресации (область)

Область адресации (address realm) представляет собой часть сети (домен), в которой обеспечивается уникальная адресация объектов, обеспечивающая возможность маршрутизации дейтаграмм между этими объектами. Используемые внутри домена протоколы маршрутизации отвечают за поиск маршрутов к объектам по сетевым адресам последних. Отметим, что этот документ ограничивается описанием NAT в среде IPv4 и не рассматривает NAT в других типах сред (например, IPv6).

2.2. Прозрачная маршрутизация

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

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

2.3. Сессии и потоки трафика

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

В контексте данного документа сессией считается подмножество трафика, управляемое, как единица (элемент) трансляции. Сессии TCP/UDP однозначно идентифицируются квадруплетом (IP-адрес отправителя, порт TCP/UDP отправителя, IP-адрес получателя, порт TCP/UDP получателя). Сессии ICMP определяются тремя параметрами (IP-адрес отправителя, идентификатор запроса ICMP, IP-адрес получателя). Все остальные сессии идентифицируются тройкой параметров (IP-адрес отправителя и получателя, протокол IP).

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

Отметим, что определение сессии в контексте NAT не будет совпадать с представлениями о сессии в приложениях. Приложение может рассматривать группу сессий NAT, как одну прикладную сессию или даже не считать обмен пакетами между партнерами какой-то сессией. Не все приложения могут работать в несовместимых областях адресации, даже при наличии ALG (определены в параграфе 2.9).

2.4. Порты TU, порты серверов и клиентов

В оставшейся части документа порты TCP/UDP, связанные с адресом IP, будут называться просто «портами TU».

Для большинства хостов TCP/IP диапазон портов TU с номерами 0-1023 используется серверами для прослушивания входящих вызовов. Инициирующие соединения клиенты обычно указывают номер порта-источника из диапазона 1024-65535. Однако это соглашение не является универсальным и выполняется не во всех случаях. Некоторые клиентские станции инициируют соединения, используя номер порта-источника из диапазона 0-1023, а некоторые серверы прослушивают порты TU с номерами из диапазона 1024-65535.

Список выделенных номеров портов TU можно найти в RFC 1700 [Ref 2].

2.5. Начало сессии для TCP, UDP и др.

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

Однако не существует детерминированного метода детектирования начала сессий UDP или других протоколов, отличных от TCP. Эвристический метод будет полагать первый пакет с не существовавшими доселе параметрами сессии (определены в параграфе 2.3), как начальный пакет новой сессии.

2.6. Завершение сессии для TCP, UDP и др.

Завершение сессии TCP детектируется подтвержденными FIN для обеих сторон или получением одной из сторон сегмента с битом RST в поле флагов TCP. Однако, поскольку устройство NAT не может знать о реальной доставке пакетов другой стороне (они могут быть отброшены на пути), оно не может быть уверенным в том, что сегменты с флагами FIN или RST3 будут последними в сессии (т. е., возможен повтор передачи). Следовательно, считать сессию завершенной можно лишь по истечение 4 минут с момента обнаружения указанных выше событий. Необходимость столь длительного ожидания описана в RFC 793 [Ref 7], где предложено значение TIME-WAIT в 2 * MSL4 (4 минуты).

Отметим, что возможны разрывы соединений TCP, которые устройство NAT не сможет детектировать (например, при перезагрузке одной из сторон). Следовательно, на устройствах NAT нужна «сборка мусора» для удаления несуществующих сессий TCP. Однако в общем случае нет возможности отличить простаивающее соединение от разорванного. Для сессий UDP нет однозначного способа детектировать разрыв сессии, поскольку протоколы на основе UDP существенно зависимы от приложений.

Для детектирования завершение сессий применяется множество эвристических методов. Например, можно считать прерванными сессии TCP, бездействующие, более 24 часов, или сессии других протоколов, не используемые в течение нескольких минут. Зачастую такие предположения будут работать, но иногда нет. Интервалы допустимого бездействия очень сильно различаются между приложениями и даже для разных сессий одного приложения. Следовательно, значения тайм-аутов должны быть настраиваемыми. Но даже это не гарантирует удовлетворительного результата. Более того, как отмечено в параграфе 2.3, нет гарантии, что представление NAT о разрыве сессии совпадет с представлением приложения.

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

2.7. Публичная/глобальная/внешняя сеть

Глобальная (Global) или публичная (Public) сеть представляет собой адресную область с уникальными для каждого узла адресами, выделенными IANA5) или другим регистратором. В контексте NAT такую сеть также будем называть внешней (External).

2.8. Частная/локальная сеть

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

В RFC 1918 [Ref 1] даны рекомендации по использованию адресного пространства в частных сетях. Агентство IANA выделило 3 блока адресов IP (10/8, 172.16/12, 192.168/16) для использования в частных сетях. В нотации, принятой до CIDR, первый блок является сетью класса A, второй представляет собой непрерывный блок из 16 сетей класса B, а третий — непрерывный блок из 256 сетей класса C.

Организация, решившая использовать в своей сети адреса из перечисленных блоков, может делать это без координации с IANA или иным регистратором, типа APNIC, RIPE и ARIN. Эти блоки адресов могут одновременно использоваться во множестве независимых организаций. Однако, если позднее такая организация пожелает организовать сетевое взаимодействие с другой организацией или подключиться к сети Internet, ей потребуется поменять блок адресов в своей сети или включить NAT на своих граничных маршрутизаторах.

2.9. Шлюзы прикладного уровня

Не все приложения легко перевести на работу через устройства NAT — в частности, это относится к приложениям, которые используют адреса IP и номера портов TCP/UDP в полях данных6. Шлюзы прикладного уровня (ALG7) обеспечивают функции специфических агентов трансляции, которые позволяют приложениям на хосте с адресом из одной области прозрачно подключаться к системам, работающим на хостах других адресных областей. ALG могут взаимодействовать с NAT для организации состояния, использовать информацию о состоянии NAT, менять содержимое полей данных прикладных пакетов и выполнять иные операции, которые могут потребоваться для работы через разнородные области адресации.

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

3. Что такое NAT?

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

  1. прозрачное выделение адресов;

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

  3. трансляция полей данных сообщений ICMP об ошибках.

На рисунке показано использование NAT в оконечном домене, подключенном к сети Internet через региональный маршрутизатор сервис-провайдера.

    \ | /                  .                               /
+---------------+  WAN     .           +-----------------+/
|Регион. Маршр. |----------------------|Маршрутиз. с NAT |---
+---------------+          .           +-----------------+\
                           .                      |        \
                           .                      |  ЛВС
                           .               ---------------
               Граница оконечного домена

Рисунок 1: Типичный сценарий работы NAT

3.1. Прозрачное выделение адресов

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

3.1.1. Статическое выделение адресов

При статическом выделении адресов выполняется взаимно-однозначное (one-to-one) отображение между адресами хостов приватной сети и внешними сетевыми адресами на время действия операции NAT. При статическом выделении адресов не требуется управлять этим выделением в зависимости от потоков данных сессий.

3.1.2. Динамическое выделение адресов

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

3.2. Прозрачная маршрутизация

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

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

3.2.1. Привязка адресов

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

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

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

3.2.2. Просмотр и трансляция адресов

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

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

3.2.3. Отвязывание адресов

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

3.3. Преобразование пакетов для сообщений об ошибках ICMP

Все сообщения ICMP об ошибках (за исключением сообщений типа Redirect) должны изменяться при прохождении через NAT. Типы сообщений ICMP об ошибках, которые нужно изменять при прохождении через NAT, включают Destination-Unreachable, Source-Quench, Time-Exceeded и Parameter-Problem. NAT не будет пытаться изменить сообщения типа Redirect.

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

4.0. Варианты NAT

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

Приведенная на рисунке схема будет служить базовой моделью для иллюстрации вариантов NAT. Host-A с адресом Addr-A размещается в приватной области, представленной сетью N-Pri. Сеть N-Pri отделена от внешних сетей маршрутизатором NAT. Host-X с адресом Addr-X размещается во внешней области, представленной сетью N-Ext. Маршрутизатор NAT с двумя интерфейсами, подключенными к разным областям, обеспечивает прозрачную маршрутизацию между этими областями. Интерфейс во внешнюю сеть имеет адрес Addr-Nx, а приватный интерфейс — Addr-Np. Следует понимать, что адреса Addr-A и Addr-Np относятся к сети N-Pri, а Addr-X и Addr-Nx — к сети N-Ext.

                           ________________
                          (                )
                         (   Область        )    +--+
                        (  внешних адресов   )-- |__|
                         (     (N-Ext)      )   /____\
                          (________________)    Host-X
                                 |              (Addr-X)
                                 |(Addr-Nx)
                     +--------------+
                     |              |
                     |маршрутиз. NAT|
                     |              |
                     +--------------+
                       |(Addr-Np)
                       |
              ----------------
             (                )
 +--+       (     Область      )
 |__|------(  приватных адресов )
/____\      (     (N-pri)      )
Host-A       (________________)
(Addr-A)

Рисунок 2. Базовая модель для иллюстрации NAT.

4.1. Traditional NAT (или) Outbound NAT

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

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

Традиционный маршрутизатор NAT на рисунке 2 будет позволять Host-A инициировать сессии с хостом Host-X, но не будет поддерживать вызовов в обратном направлении. Адреса N-Ext являются маршрутизируемыми внутри N-Pri, но адреса N-Pri не будут маршрутизироваться в N-Ext.

Traditional NAT обычно используется сайтами с адресами из приватных блоков для доступа во внешние сети.

Существует два варианта традиционной NAT — базовый (Basic NAT) и NAPT9 (трансляция адресов и портов). Оба варианта рассматриваются в двух следующих параграфах.

4.1.1. Basic NAT

В Basic NAT для трансляции адресов хостов приватной сети используется блок внешних адресов при организации соединений из приватной сети со внешними доменами. Для исходящих из приватной сети пакетов IP-адрес отправителя и связанные поля типа контрольных сумм заголовков IP, TCP, UDP и ICMP соответствующим образом транслируются. Для принимаемых пакетов транслируется адрес получателя и указанные контрольные суммы.

Маршрутизатор Basic NAT на рисунке 2 может быть настроен на трансляцию N-Pri в блок адресов (например, Addr-i — Addr-n), выбранных из внешней сети N-Ext.

4.1.2. Трансляция адресов и номеров портов (NAPT)

NAPT расширяет трансляцию, добавляя возможность преобразования идентификаторов транспортного уровня (например, номера порта TCP или UDP, идентификатора запроса ICMP). Это позволяет мультиплексировать транспортные идентификаторы множества приватных хостов в транспортные идентификаторы одного внешнего адреса. NAPT позволяет множеству внутренних хостов пользоваться одним внешним адресом. Отметим, что NAPT может комбинироваться с Basic NAT, чтобы использовать блок внешних адресов вкупе с трансляцией портов.

Для исходящих из приватной сети пакетов NAPT будет транслировать IP-адрес и транспортный идентификатор отправителя, а также такие поля, как контрольные суммы заголовков IP, TCP, UDP и ICMP. Транспортными идентификаторами могут служить номера портов TCP/UDP или идентификаторы запросов ICMP. Для входящих пакетов будут транслироваться IP-адрес и транспортный идентификатор получателя, а также контрольные суммы заголовков.

Маршрутизатор NAPT на рисунке 2 можно настроить на трансляцию сессий, организованных из N-Pri, на один внешний адрес (например, Addr-i).

Зачастую при трансляции адресов N-Pri они отображаются на внешний адрес Addr-Nx маршрутизатора NAPT.

4.2. Bi-directional NAT (или) Two-Way NAT

При двухсторонней трансляции (Bi-directional NAT) сессии могут инициироваться как с хостов приватной сети, так и из внешней сети. Адреса приватной сети привязываются к уникальны в глобальном масштабе адресам статически или динамически при организации сессий в обоих направлениях. В пространстве имен (т. е., FQDN10) для хостов приватной и внешних сетей предполагается уникальность каждого имени. Хосты из внешней области получают доступ к хостам внутренней области, используя для преобразования имен в адреса систему DNS. В дополнение к Bi-Directional NAT требуется развертывание DNS-ALG для корректного отображения адресов. В частности, с помощью DNS-ALG должна обеспечиваться возможность трансляции адресов из приватной области в запросах и откликах DNS на внешние привязки для этих адресов (и обратно) при прохождении пакетов DNS между приватной и внешней областями.

Требования к адресному пространству, отмеченные для Traditional NAT, применимы и в данном случае.

Маршрутизатор Bi-directional NAT на рисунке 2 позволит Host-A инициировать сессии с Host-X, а Host-X, в свою очередь — инициировать сессии с Host-A. Как и для традиционной трансляции NAT, адреса N-Ext будут маршрутизироваться в N-Pri, но адреса N-Pri не будут маршрутизироваться из N-Ext.

4.3. Twice NAT

Двойная трансляция (Twice NAT) — это вариант NAT, в котором устройство NAT при прохождении дейтаграммы через границу между сетями меняет адреса как отправителя, так и получателя. Этим данный вариант отличается от Traditional-NAT и Bi-Directional NAT, где преобразуется лишь один из адресов (отправителя или получателя, в зависимости от направления). Отметим, что термин Once-NAT (однократная трансляция) не используется.

Twice NAT требуется использовать в тех случаях, когда адресные пространства внешней и внутренней сети конфликтуют между собой11. Наиболее вероятно возникновение такой ситуации при некорректном применении во внутренней публичных адресов из блока, выделенного другой организации. Аналогичная ситуация может возникнуть и при смене организацией провайдера без замены внутренних адресов, выделенных прежним провайдером. Основной проблемой в таких случаях является совпадение части адресов внутренней и внешней сетей. При указании такого адреса в заголовке пакета этот пакет будет направлен скорей всего внутреннему хосту, а не на устройство NAT для трансляции. Twice-NAT пытается организовать мост между двумя областями путем трансляции адресов отправителя и получателя в пакетах IP при пересечении пакетом границы между областями.

Twice-NAT работает следующим образом. Когда Host-A инициирует сессию с Host-X, он отправляет запрос DNS для имени Host-X. Система DNS-ALG перехватывает запрос DNS и в отклике возвращаемом на хост Host-меняет адрес Host-X на адрес, для которого обеспечивается корректная маршрутизация на локальном сайте (например, Host-XPRIME). После этого Host A инициирует взаимодействие с Host-XPRIME. Когда пакеты проходят через устройство NAT, IP-адрес отправителя транслируется (как в Traditional NAT), а адрес получателя транслируется в адрес Host-X. Аналогичные преобразования выполняются для пакетов, приходящих от Host-X.

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

Маршрутизатор Twice NAT на рисунке 2 будет позволять Host-A инициировать сессии с Host-X, а Host-X — инициировать сессии с Host-A. Однако сеть N-Ext (или подмножество N-Ext) не будет маршрутизироваться из сети N-Pri, а сеть N-Pri не будет маршрутизироваться из N-Ext.

Twice NAT обычно используется в тех случаях, когда адресное пространство внутренней сети пересекается с адресным пространством внешней сети. Например, на приватном сайте, использующем блок адресов 200.200.200.0/24, официально выделенный другому сайту во внещней сети. Предположим, что Host_A (200.200.200.1) из приватной сети Private пытается связаться с Host_X (200.200.200.100) во внешней сети Public. Для организации такого соединения адрес Host_X отображается на другой адрес для Host_A (и обратно). Двойную трансляцию на граничном маршрутизаторе сети Private можно настроить следующим образом:

Private -> Public : 200.200.200.0/24 -> 138.76.28.0/24
Public <- Private : 200.200.200.0/24 -> 172.16.1.0/24
Поток дейтаграмм : Host_A(Private) -> Host_X(Public)
  1. В приватной сети

DA: 172.16.1.100 SA: 200.200.200.1
  1. После трансляции twice-NAT

DA: 200.200.200.100 SA: 138.76.28.1
Datagram flow Host_X (Public) -> Host_A (Private)
  1. В публичной сети

DA: 138.76.28.1 SA: 200.200.200.100
  1. В приватной сети после трансляции twice-NAT

SA: 200.200.200.1 DA: 172.16.1.100

4.4. Multihomed NAT

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

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

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

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

5.0. Специфические для области адреса IP (RSIP)

Аббревиатура RSIP12 используется для обозначения функциональности (осведомленного о наличии областей) хоста из приватной сети принимать специфический для области адрес IP для взаимодействия с хостом приватной или внешней области.

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

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

Существует два варианта RSIP — RSA-IP13 и RSAP-IP14, которые описаны ниже.

5.1. Специфический для области адрес (RSA-IP)

Клиент RSA-IP принимает адрес IP из внешнего адресного пространства при соединении с хостом из внешней области. После того, как клиент RSA-IP примет внешний адрес, ни один другой хост приватной или внешней сети не сможет принимать этот адрес, пока он не будет освобожден клиентом RSA-IP.

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

Например, Host-A на рисунке 2 может принять адрес Addr-k из внешней области и действовать, как клиент RSA-IP, чтобы обеспечить возможность организации сквозных сессий между Addr-k и Addr-X. Прохождение пакетов через приватную область можно проиллюстрировано ниже.

Первый метод использует трансляцию на маршрутизаторе NAT.

      ======================================================
   Host-A               маршрутизатор NAT        Host-X
   ------               -----------------        ------
   <Внешний заголовок IP с
   src=Addr-A, Dest=Addr-X>,
   вложенный <«сквозной» пакет с
   src=Addr-k, Dest=Addr-X>
   ----------------------------->
                        <Внешний заголовок IP с
                        src=Addr-k, Dest=Addr-X>,
                        вложенный <«сквозной» пакет с
                        src=Addr-k,  Dest=Addr-X>
                        --------------------------->
                             .
                             .
                             .
                                              <Внешний заголовок IP с
                                              src=Addr-X, Dest=Addr-k>,
                                              вложенный <«сквозной» пакет с
                                              src=Addr-X, Dest=Addr-k>
                                     <---------------------------------
                        <Внешний заголовок IP с
                        src=Addr-X, Dest=Addr-A>,
                        вложенный <«сквозной» пакет с 
                        src=Addr-X, Dest=Addr-k>
              <--------------------------------------

Второй метод использует туннель внутри приватной области.

      ======================================================
   Host-A               маршрутизатор NAT        Host-X
   ------               -----------------        ------
   <Внешний заголовок IP с
   src=Addr-A, Dest=Addr-Np>,
   вложенный <«сквозной» пакет с
   src=Addr-k, Dest=Addr-X>
   ----------------------------->
                        <«Сквозной» пакет с 
                        src=Addr-k, Dest=Addr-X>
                        ------------------------------->
                             .
                             .
                             .
                                             <«Сквозной» пакет с 
                                             src=Addr-X, Dest=Addr-k>
                                    <--------------------------------
                        <Внешний заголовок IP с
                        src=Addr-Np, Dest=Addr-A>,
                        вложенный <«сквозной» пакет с
                        src=Addr-X, Dest=Addr-k>
                  <----------------------------------

Могут использоваться и другие варианты.

Ниже приведены характеристики клиента RSA-IP. Набор выполняемых клиентом RSA-IP операций может быть обозначен термином RSA-IP.

  1. Осведомлен об областях, в которых могут размещаться партнерские узлы.

  2. Принимает адрес из внешней области при взаимодействии с хостами из данной области. Адрес может присваиваться статически или выделяться динамическими (протокол будет определен) узлом, способным выделять адреса из внешней области. Распределение адресов из внешней области может координировать сервер RSA-IP.

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

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

  1. Может обеспечивать статическое или динамическое выделение адресов из внешней области клиентам RSA-IP.

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

  3. Должен обеспечивать механизм маршрутизации пакетов из внешней области внутри приватной области. Описаны два варианта такой маршрутизации.

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

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

Клиенты RSA-IP могут применять любые методы IPsec (а именно, транспортный или туннельный режим с поддержкой аутентификации и шифрования на основе заголовков AH и ESP во вложенных пакетах). Для инкапсуляции между клиентом RSA-IP и сервером RSA-IP или внешним хостом могут применяться любые методы туннелирования. Например, инкапсуляция в туннельном режиме IPsec является корректным типом инкапсуляции, которая обеспечивает аутентификацию и шифрование IPsec для вложенных сквозных пакетов.

5.2 Специфический для области адрес и порт (RSAP-IP)

RSAP-IP является вариантом RSIP, в котором множество хостов приватной области может использовать один внешний адрес с мультиплексированием по идентификаторам транспортного уровня (номерам портов TCP/UDP, ICMP Query ID).

Клиент RSAP-IP может быть определен по аналогии с клиентом RSA-IP, но при соединении с хостами внешней области он получает не только адрес, но и идентификатор транспортного уровня. В связи с этим коммуникации клиентов RSAP-IP с внешними областями могут быть ограничены сессиями TCP, UDP и ICMP.

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

Маршрутизатор NAPT может работать в качестве сервера RSAP-IP, когда внешняя инкапсуляция основана на TCP/UDP и пакеты передаются между клиентом RSAP-IP и внешним партнером. В этой модели внешний партнер должен быть конечной точкой туннеля TCP/UDP. Клиенты RSAP-IP могут использовать любые методы IPsec (а именно, транспортный или туннельный режим с поддержкой аутентификации и шифрования на основе заголовков AH и ESP во вложенных пакетах). Отметим, однако, что туннельный режим IPsec не является подходящим типом инкапсуляции, поскольку маршрутизатор NAPT не может обеспечить прозрачной маршрутизации для протоколов AH и ESP.

В другом варианте пакеты могут туннелироваться между клиентом и сервером RSAP-IP, а сервер будет детуннелировать пакеты от клиентов RSAP-IP и пересылать их внешним хостам. На обратном пути сервер RSAP-IP будет находить туннель с клиентом RSAP-IP по паре (адрес — порт получателя) и инкапсулировать исходный пакет в туннель для пересылки клиенту RSAP-IP. В этом варианте не возникает ограничений на методы туннелирования между клиентом и сервером RSAP-IP. Однако здесь возникают ограничения на сквозное использование защиты на основе IPsec. В транспортном режиме может быть обеспечена аутентификация и защита целостности. Однако конфиденциальность защитить не удастся, поскольку сервер RSAP-IP должен иметь доступ к транспортному идентификатору получателя для определения туннели RSAP-IP. По этой причине через сервер RSAP-IP в этом варианте могут проходить только пакеты TCP, UDP и ICMP в транспортном режиме IPsec с защитой AH и ESP.

В качестве примера предположим, что Host-A на рисунке 2 получает пару (Addr-Nx, TCP port T-Nx) от маршрутизатора NAPT для работы в качестве клиента RSAP-IP с целью организации сквозной сессии TCP с Host-X. Прохождение пакетов через приватную область проиллюстрировано ниже. В первом варианте внешний уровень исходящего от Host-A пакета использует пару (приватный адрес Addr-A, порт отправителя T-Na) для взаимодействия с Host-X. Маршрутизатор NAPT транслирует эту пару в (Addr-Nx, Port T-Nxa). Трансляция не зависит от параметров адресации клиента RSAP-IP, указанных во вложенном пакете.

В первом варианте используется маршрутизатор NAPT для трансляции:

      ======================================================
   Host-A               маршрутизатор NAT        Host-X
   ------               -----------------        ------
   <Внешний пакет TCP/UDP с
   src=Addr-A, Src Port=T-Na, Dest=Addr-X>,
   вложенный <«сквозной» пакет с 
   src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
   ----------------------------->
                        <Внешний пакет TCP/UDP с
                        src=Addr-Nx, Src Port=T-Nxa, Dest=Addr-X>,
                        вложенный <«сквозной» пакет с
                        src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
                        --------------------------------------->
                             .
                             .
                             .
                                             <Внешний пакет TCP/UDP с
                                             src=Addr-X, Dest=Addr-Nx, Dest Port=T-Nxa>,
                                             вложенный <«сквозной» пакет с
                                             src=Addr-X, Dest=Addr-Nx, Dest Port=T-Nx>
                                     <----------------------------------
                        <Внешний пакет TCP/UDP с
                        src=Addr-X, Dest=Addr-A, Dest Port=T-Na>,
                        вложенный <«сквозной» пакет с
                        src=Addr-X, Dest=Addr-Nx, Dest Port=T-Nx>

Во втором варианте организуется туннель в приватной области:

      ======================================================
   Host-A               маршрутизатор NAT        Host-X
   ------               -----------------        ------
   <Внешний заголовок IP с
   src=Addr-A, Dest=Addr-Np>,
   вложенный <«сквозной» пакет с
   src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
   ----------------------------->
                        <«сквозной» пакет с
                        src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
                        -------------------------------->
                             .
                             .
                             .
                                             <«сквозной» пакет с
                                             src=Addr-X, Dest=Addr-Nx, Dest Port=T-Nx>
                                   <----------------------------------
                        <Внешний заголовок IP с
                        src=Addr-Np, Dest=Addr-A>,
                        вложенный <«сквозной» пакет с
                        src=Addr-X, Dest=Addr-Nx, Dest Port=T-Nx>
                <----------------------------------

6.0. Приватные сети и туннели

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

Ниже рассмотрены использования туннелей (a) с трансляцией адресов и (b) без таковой.

6.1. Туннелирование транслированных пакетов

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

Например, приватная сеть, подключенная к деловому партнеру через облако VPN, может применять традиционную NAT для обмена информацией с партнером. При пересечении адресных пространств в сетях партнеров можно воспользоваться Twice NAT. Устройство NAT может быть установлено как на одной стороне туннеля, так и на обоих его концах. Во всех случаях трафик через VPN может шифроваться для обеспечения его защиты в сети VPN. Для сквозной защиты трафика потребуется использование в приватной сети доверенного устройства NAT.

6.2. Приватные сети, сегментированные магистралями

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

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

Когда NAT-устройство x в оконечном сегменте X желает доставить пакет в оконечный сегмент Y, оно будет инкапсулировать пакет с указанием во внешнем заголовке глобального IP-адреса NAT-устройства y. Когда NAT-устройство y получит пакет со своим адресом во внешнем заголовке, оно будет декапсулировать пакет и пересылать его адресату в своей локальной сети. Отметим, что в этом случае трансляция адресов не используется и пакеты приватной сети просто туннелируются через магистраль.

7.0. Рабочие характеристики NAT

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

Устройства NAT (не включая ALG) не проверяют и не меняют данные транспортного уровня. По этой причине во многих случаях устройства NAT прозрачны для приложений. Однако существуют две области, в которых использование устройств NAT может создавать сложности: 1) данные приложений включают адреса IP и 2) требуется сквозное обеспечение защиты. Отметим, что могут быть и другие задачи, где трансляция создает проблемы.

Методы защиты на прикладных уровнях, не использующие адресов IP и не зависящие от них, будут корректно работать через NAT (например, TLS, SSL и ssh). Напротив, методы защиты на транспортном уровне (например, транспортный режим IPSec или TCP MD5 Signature Option RFC 2385 [17]) не будут работать при трансляции адресов.

В транспортном режиме IPSec контроль целостности для AH и ESP целиком включает поле данных (payload) пакета. Если данные относятся к протоколу TCP или UDP, контроль целостности учитывает и поле контрольной суммы TCP/UDP. Когда устройство NAT меняет адрес, контрольная сумма с учетом нового адреса становится иной. Обычно NAT обновляет и поле контрольной суммы, но этого сделать нельзя при использовании AH или ESP. Следовательно, получатели будут отбрасывать пакеты по результатам проверки целостности IPSec (если устройство NAT изменяет контрольную сумму) или по причине некорректности контрольной суммы (если NAT ее не меняет).

Отметим, что IPsec в туннельном режиме ESP можно применять, пока на содержимое вложенных пакетов не оказывает влияния трансляция внешнего заголовка IP. Хотя этот метод не работает с традиционной NAT (где хосты просто не знают о наличии NAT), он применим к трансляции Realm-Specific IP, описанной в параграфе 5.0.

Отметим также сквозная аутентификация и защита конфиденциальности в транспортном режиме на основе ESP может использоваться для таких пакетов, как ICMP, где содержимое поля данных IP не меняется в результате трансляции внешнего заголовка IP.

Устройства NAT также нарушают фундаментальные допущения инфраструктур распределения открытых ключей типа Secure DNS RFC 2535 [18] и сертификатов X.509 с подписанными открытыми ключами. В случае Secure DNS каждый набор DNS RRset подписывается ключом зоны. Кроме того, аутентичность конкретного ключа проверяется по цепочке доверия до корня DNS. Когда DNS-ALG меняет адреса (например, в случае Twice-NAT), проверка подписи завершается отказом.

Будет интересно отметить, что IKE (протокол согласования сеансовых ключей) представляет собой основанный на UDP протокол сеансового уровня и не защищен с помощью IPsec. Защищена лишь часть данных IKE. По этой причине сессии IKE могут проходить через NAT, пока данные IKE не включают адресов или транспортных идентификаторов, специфичных для одной области и не известных другой. С учетом того, что IKE используется для организации защищенных связей IPSec и в настоящее время не известно способов организации работы IPSec через NAT, следует вести работу в направлении использования IKE через NAT.

Одно из популярных Internet-приложений FTP не работает с NAT, как описано выше. В следующем параграфе описана поддержка FTP в устройствах NAT. FTP ALG является встроенной частью большинства реализаций NAT. Некоторые разработчики могут включать дополнительные ALG для поддержки работы других приложений через NAT.

7.1. Поддержка FTP

Команда PORT и отклик на команду PASV в данных управления сеансом FTP идентифицируют IP-адрес и номер порта TCP, которые должны использоваться для передачи данных в этой сессии. Аргументами команды PORT и отклика на команду PASV являются адрес IP и номер порта TCP в формате ASCII. Шлюз FTP ALG должен контролировать и обновлять данные управления сеансом FTP, чтобы содержащаяся в них информация относилась к нужным оконечным узлам. Шлюз ALG должен также обновлять NAT с учетом пар адрес-порт и направления сессии, чтобы устройство NAT могло поддерживать состояние для сессий передачи данных FTP.

Поскольку адреса и номера портов TCP указываются в формате ASCII, изменение этих параметров может приводить к изменению размера пакетов. Например, последовательность 10,18,177,42,64,87 имеет размер 18 символов ASCII, а 193,45,228,137,64,87 — 20 символов. Если размер пакета сохраняется, требуется лишь заново рассчитать контрольную сумму TCP. Однако при изменении размера пакета требуется менять порядковые номера TCP с учетом изменения размера управляющих данных FTP. В устройствах ALG могут применяться специальные таблицы для корректировки порядковых номеров и номеров подтверждений TCP. Корректировка порядковых номеров и номеров подтверждений должна выполняться и для всех последующих пакетов данного соединения.

8.0. Ограничения NAT

8.1. Приложения с адресами IP в поле данных

Не все приложения легко можно адаптировать для работы через устройства NAT. В частности, сложности возникают с приложениями, которые передают адрес IP (и номер порта в случае NAPT) в поле данных пакетов. Для таких приложений требуется использовать специализированные шлюзы прикладного уровня (ALG16). Шлюзы ALG могут предоставлять адреса (и номера портов), подобно NAT, а также выполнять специфическую трансляцию, нужную для работы приложения. Комбинация функций NAT и ALG не позволяет организовать сквозную защиту с помощью IPsec. Однако можно воспользоваться туннельным режимом IPsec с маршрутизатором NAT в качестве окончания туннеля.

Приложения SNMP17 относятся к числу передающих адреса в поле данных пакетов. Маршрутизаторы NAT не будут транслировать такие адреса IP в пакетах SNMP. Зачастую для SNMP применяются специализированные ALG (на маршрутизаторе NAT) для трансляции SNMP MIB18 в приватной сети.

8.2. Приложения со связанными сессиями для управления и данных

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

Однако существуют приложения (например, H.323), которые используют одну или несколько сессий для управления характеристиками сеанса обмена данными. Для таких приложений нужны специализированные шлюзы ALG, способные анализировать и интерпретировать данные сессии. Такая интерпретация будет помогать NAT в обработке связанных сессий передачи данных.

8.3. Отладка

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

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

8.4. Трансляция фрагментированных пакетов управления FTP

Трансляция фрагментированных пакетов управления FTP, содержащих команду PORT или отклик на команду PASV, достаточно сложна. Ясно, что в этом (патологическом) случае маршрутизатору NAT может потребоваться сборка фрагментов до трансляции и пересылки пакета.

Другая ситуация возникает когда каждый символ пакета с командой PORT или откликом на команду PASV передается в отдельной дейтаграмме (без фрагментирования). В этом случае NAT будет просто пропускать пакеты без трансляции данных TCP. Если для приложения такая трансляция нужна, неизбежно возникнет отказ в его работе. В редких случаях приложение будет работать, если содержимое данных корректно в обеих адресных областях. Например, сеанс FTP с хоста приватной сети будет работать при прохождении после традиционной или двухсторонней трансляции NAT, пока у управляющей сессии FTP используется команда PASV для организации сессий передачи данных. Причина этого заключается в том, что адрес и номер порта, заданные сервером FTP в отклике на команду PASV (переданном во множестве пакетов без фрагментирования), будут корректны для приватного хоста без их трансляции. Устройство NAT будет просто рассматривать сессию передачи данных (с того же приватного хоста), как независимый сеанс TCP.

8.5. Вычислительные ресурсы

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

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

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

Если устройства NAT и ALG не находятся в доверенной зоне, это вызывает существенные проблемы безопасности, поскольку ALG могут просматривать данные из пользовательского трафика. Данные сеансового уровня можно зашифровать, если эти данные не содержат адресов IP и транспортных идентификаторов, которые требуют трансляции. За исключением случая RSIP, сквозная защита на уровне IP с помощью IPsec не может применяться при наличии NAT. Одной из конечных точек должно быть устройство NAT. В параграфе 7.0 было показано, почему сквозная защита IPsec не может быть реализована при наличии в пути устройств NAT.

Совместное использование NAT, ALG и межсетевых экранов будет обеспечивать прозрачную среду для приватного сетевого домена. За исключением случая RSIP, сквозная защита на сетевом уровне с помощью IPsec не может быть обеспечена для хостов приватной сети (работа RSIP описана в параграфе 5.0). В остальных случаях для сквозной защиты IPsec на пути передачи не должно быть устройств NAT. Если устройства NAT находятся в доверенной зоне, можно реализовать туннельный режим IPsec с использованием в качестве конечной точки туннеля устройства NAT (или комбинации NAT, ALG и межсетевого экрана).

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

Ниже перечислены некоторые проблемы безопасности, связанные с маршрутизаторами NAT.

  1. Сессии UDP не защищены по своей природе. Отклики на дейтаграммы могут приходить с адреса, отличающегося от указанного отправителем в исходном пакете [4]. В результате входящие пакеты UDP могут лишь частично соответствовать исходящим сессиям традиционной трансляции NAT (адрес и порт получателя будут соответствовать, адрес и порт отправителя — не будут). В таких случаях могут возникать проблемы безопасности, если устройство NAT будет принимать пакеты с частичным соответствием. Проблемы безопасности UDP присущи и межсетевым экранам.

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

  2. Групповые адреса (для UDP) создают другую проблему безопасности для традиционных маршрутизаторов NAT. Снова подчеркнем, что такая же проблема присуща межсетевым экранам.

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

  3. Устройства NAT могут быть целью атак.

    Поскольку устройства NAT являются хостами Internet, они могут подвергаться различным атакам, включая лавинную передачу пакетов SYN или ping. Устройства NAT должны поддерживать те или иные методы защиты себя, как это делается на серверах Internet.

Литература

[1] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[2] Reynolds, J. and J. Postel, «Assigned Numbers», STD 2, RFC 170019, October, 1994.

[3] Braden, R., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[4] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

[5] Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.

[6] Postel, J. and J. Reynolds, «File Transfer Protocol (FTP)», STD 9, RFC 959, October 1985.

[7] Postel, J., «Transmission Control Protocol (TCP) Specification», STD 7, RFC 793, September 1981.

[8] Postel, J., «Internet Control Message Protocol Specification» STD 5, RFC 792, September 1981.

[9] Postel, J., «User Datagram Protocol (UDP)», STD 6, RFC 768, August 1980.

[10] Mogul, J. and J. Postel, «Internet Standard Subnetting Procedure», STD 5, RFC 950, August 1985.

[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, «IPv4 Address Behavior Today», RFC 2101, February 1997.

[12] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240120, November 1998.

[13] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 240621, November 1998.

[14] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 240222, November 1998.

[15] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 240923, November 1998.

[16] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 24072, November 1998.

[17] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[18] Eastlake, D., «Domain Name System Security Extensions», RFC 253524, March 1999.

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

Pyda Srisuresh

Lucent Technologies

4464 Willow Road

Pleasanton, CA 94588-8519

U.S.A.

Phone: (925) 737-2153

Fax: (925) 737-2110

EMail: srisuresh@lucent.com

Matt Holdrege

Lucent Technologies

1701 Harbor Bay Parkway

Alameda, CA 94502

Phone: (510) 769-6001

EMail: holdrege@lucent.com

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

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Network Address Translation — трансляция сетевых адресов.

2Application level gateway.

3В оригинале ошибочно сказано SYN. См. http://www.rfc-editor.org/errata_search.php?eid=400. Прим. перев.

4Maximum Segment Lifetime — максимальное время жизни сегмента.

5Internet Assigned Numbers Authority.

6Не в заголовках. Прим. перев.

7Application Level Gateway.

8Network Address Translation.

9Network Address Port Translation.

10Fully Qualified Domain Name — полное доменное имя.

11Не обеспечивается уникальности адресов. Прим. перев.

12Realm Specific IP.

13Realm Specific Address IP.

14Realm Specific Address and port IP.

15Virtual private network — виртуальная частная сеть.

16Application Level Gateway.

17Simple Nework Management Protocol – простой протокол сетевого управления. Прим. перев.

18Management Information Base – база управляющей информации. Прим. перев.

19В соответствии с RFC 3232 документ Assigned Numbers утратил силу. Данные сейчас доступны по ссылке.

20Документ признан устаревшим и заменен RFC 4301. Прим. перев.

21Документ признан устаревшим и заменен RFC 4303 и RFC 4305. Прим. перев.

22Документ признан устаревшим и заменен RFC 4302 и RFC 4305. Прим. перев.

23Документ признан устаревшим и заменен RFC 4306. Прим. перев.

24Документ признан устаревшим и заменен RFC 4033, RFC4034, RFC4035. Прим. перев.




RFC 2673 Binary Labels in the Domain Name System

Network Working Group                             M. Crawford
Request for Comments: 2673                           Fermilab
Updates: 1035                                     August 1999
Category: Standards Track

Двоичные метки в DNS

Binary Labels in the Domain Name System

PDF

Статус документа

В этом документе описан предлагаемый стандарт протокола для сообщества Internet; документ служит приглашением к дискуссии в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Данный документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Введение и терминология

В этом документе определены метки, представляющие собой строку битов (Bit-String Label), которые могут появляться в доменных именах. Новый тип меток компактно представляет последовательность однобитовых меток (One-Bit Label) и позволяет сохранять записи о ресурсах в любых битах раздела binary-named в дереве доменных имен.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [KWORD].

2. Мотивация

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

3. Формат меток

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

Среди последовательных меток в форме битовой строки биты, появляющиеся первыми, являются менее значимыми (биты нижнего уровня), нежели биты последующих меток Bit-String (как и при упорядочении меток ASCII).

3.1. Представление

 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
|0 1|    ELT    |     Count     |           Label …         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+

(каждая «клеточка» представляет 1 бит)

ELT — двоичное значение 000001 — шестибитовое значение расширенного типа метки [EDNS0], выделенное для Bit-String Label.

Count — число значимых битов в поле Label. Нулевое значение поля Count говорит о размере метки 256 битов (таким образом, пустая метка, обозначающая корень DNS, не может быть представлена в формате Bit-String).

Label — строка битов, представляющая собой последовательность однобитовых меток, в которой старший бит указывается первым (т. е., однобитовая метка в позиции 17 на рисунке представляет субдомен домена, представленного однобитовой меткой в позиции 16 и т. д.).

Поле Label дополняется справа битами заполнения (от 0 до 7) для выравнивания размера метки в целом по границе октета. Для заполнения при передаче должно использоваться значение 0, которое должно игнорироваться на приемной стороне.

Последовательность битов может быть расщеплена на две или более метки Bit-String, но точка раздела не имеет значения и ее не требуется сохранять. Изощренные реализации серверов могут делить метки Bit-String для повышения эффективности сжатия сообщений [DNSIS]. Более простые серверы могут делить метки Bit-String по границам зон, если какая-нибудь из таких границ попадает между однобитовыми метками.

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

Метки в форме битовых строк представляются в текстовом формате (например, в файлах зон), как <bit-spec>, окруженные в качестве граничных маркеров символами \[ и ]. <bit-spec> представляет собой квартет с разделением точки или индикатор базы и последовательность цифр, подходящих для этой базы, за которыми может следовать символ дробной черты и поле размера. В качестве индикаторов базы используются символы b, o и x для обозначения базы 2, 8 и 16, соответственно. Поле размера учитывает значимые биты и должно иметь значение от 1 до 32, включительно, для разделенных точками квартетов или от 1 до 256, включительно, для других форм. Если размер опущен, используется неявное значение 32 для квартетов с точками или 1-, 3- или 4-кратное число двоичных, восьмеричных или шестнадцатеричных цифр в остальных вариантах представления.

Расширенная форма Бэкуса-Наура [ABNF] имеет вид

bit-string-label = «\[» bit-spec «]»
bit-spec         = bit-data [ «/» length ]
                 / dotted-quad [ «/» slength ]
bit-data         = «x» 1*64HEXDIG
                 / «o» 1*86OCTDIG
                 / «b» 1*256BIT
dotted-quad      = decbyte «.» decbyte «.» decbyte «.» decbyte
decbyte          = 1*3DIGIT
length           = NZDIGIT *2DIGIT
slength          = NZDIGIT [ DIGIT ]
OCTDIG           = %x30-37
NZDIGIT          = %x31-39

При наличии поля <length>, числа цифр в <bit-data> должно быть достаточно для размещения количества битов, заданного полем <length>. При наличии неиспользуемых битов в шестнадцатеричной или восьмеричной цифре эти биты должны иметь значение 0. Поле <dotted-quad> всегда имеет все 4 части, даже если связанное с ним значение <slength> меньше 24. Подобно другим формам неиспользуемые биты должны иметь значение 0.

Каждое число, представляемое <decbyte> должно иметь значение от 0 до 255, включительно.

Число, представленное полем <length> должно иметь значение от 1 до 256, включительно.

Число, представленное полем <slength> должно иметь значение от 1 до 32, включительно.

Когда текстовое представление метки Bit-String генерируется машиной, размер следует указывать явно, не основываясь на принятых по умолчанию значениях.

3.2.1. Примеры

Ниже показаны 4 варианта текстового представления одной метки Bit-String.

\[b11010000011101]
\[o64072/14]
\[xd074/14]
\[208.116.0.0/14]

Ниже представлены две последовательные метки Bit-String, которые обозначают ту же относительную точку в дереве DNS, что и показанные выше одиночные метки Bit-String.

\[b11101].\[o640]

3.3. Каноническое представление и порядок сортировки

Как для сигнальной (передаваемой), так и для текстовой формы представления двоичных меток обеспечивается уровень гибкости, достаточный для для их группировки в последовательность меток Bit-String. Для генерации и проверки подписей DNS [DNSSEC] двоичные метки должны иметь предсказуемую форму. Эта каноническая форма определяется, как минимальная возможная последовательность меток Bit-String, в которой все метки, за возможным исключением первой, имеют максимальный размер.

Например, каноническая форма любой последовательности, содержащей до 256 однобитовых меток имеет одну метку Bit-String, а каноническая форма последовательности из 513 — 768 однобитовых меток имеет три метки Bit-String, из которых вторая и треться содержат по 256 битов.

Канонический порядок сортировки доменных имен [DNSSEC] расширяется с учетом применения двоичных меток. Сортировка продолжает осуществляться пометочно (label-by-label), от наименее значимой метки (метка может быть однобитовой или стандартной — код 00). Любая однобитовая метка помещается при сортировке перед всеми стандартными метками, а значение 0 — впереди значения 1. Отсутствующая метка при сортировке помещается впереди всех меток, как указано в [DNSSEC].

Ниже приведен пример корректно отсортированных доменных имен.

foo.example
\[b1].foo.example
\[b100].foo.example
\[b101].foo.example
bravo.\[b10].foo.example
alpha.foo.example

4. Правила обработки

Однобитовая метка никогда не соответствует какой-либо метке иного типа. В частности метки DNS, представленные символами ASCII 0 и 1 не соответствуют однобитовым меткам со значениями 0 и 1.

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

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

6. Согласование с IANA

В этом документе определяется расширенный тип метки (Extended Label Type) под названием Bit-String Label и запрашивается регистрация двоичного кода 000001 в пространстве имен, определенном [EDNS0].

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

Все вопросы безопасности, относящиеся к традиционным ASCII-меткам DNS, в такой же мере применимы и к двоичным меткам. Правила канонизации и сортировка (параграф 3.3) позволяют решать эти вопросы с помощью DNS Security [DNSSEC].

8. Литература

[ABNF] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 22341, November 1997.

[DNSIS] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 10351, November 1987.

[DNSSEC] Eastlake, D., 3rd, C. Kaufman, «Domain Name System Security Extensions», RFC 2065, January 1997

[EDNS0] Vixie, P., «Extension mechanisms for DNS (EDNS0)», RFC 2671, August 1999.

[KWORD] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels,» BCP 14, RFC 21191, March 1997.

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

Matt Crawford

Fermilab MS 368

PO Box 500

Batavia, IL 60510

USA

Phone: +1 630 840-3461

EMail: crawdad@fnal.gov

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

Николай Малых

nmalykh@protocols.ru

10. Полное заявление авторских прав

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Перевод этого документа на русский язык имеется на сайте www.protocols.ru. Прим. перев.




RFC 2661 Layer Two Tunneling Protocol «L2TP»

Network Working Group                                        W. Townsley
Request for Comments: 2661                                   A. Valencia
Category: Standards Track                                  cisco Systems
                                                               A. Rubens
                                                   Ascend Communications
                                                                 G. Pall
                                                                 G. Zorn
                                                   Microsoft Corporation
                                                               B. Palter
                                                        Redback Networks
                                                             August 1999

 

Протокол туннелирования на уровне 2 — L2TP

Layer Two Tunneling Protocol «L2TP»

PDF

Статус документа

Этот документ задает проект стандартного протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования. Текущее состояние стандартизации и статус протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

Тезисы

В этом документе описан протокол туннелирования на уровне 2 (L2TP1). Документ STD 51, RFC 1661 определяет мультипротокольный доступ по протоколу PPP [RFC1661]. L2TP обеспечивает возможности туннелирования пакетов PPP через промежуточную сеть максимально прозрачным для приложений и конечных пользователей способом.

Оглавление

Ислючено в версии HTML.

1.0 Введение

PPP [RFC1661] определяет механизм инкапсуляции для доставки пакетов разных протоколов через соединения уровня 2 (L2) типа «точка-точка». Обычно пользователь организует соединение L2 с сервером доступа (NAS2), используя подходящий метод связи (например, модемное соединение через телефонную линию, ISDN, ADSL и т. п.) и протокол PPP «поверх» физического соединения. В такой конфигурации терминальные точки L2 и PPP размещаются на одном физическом устройстве (т. е., NAS).

L2TP расширяет модель PPP, позволяя разносить терминальные точки L2 и PPP на разные устройства, соединенные через сеть с коммутацией пакетов. С помощью L2TP пользователь организует соединение L2 с концентратором доступа (например, модемный пул, ADSL DSLAM и т. п.), а концентратор туннелирует кадры PPP в NAS. Это позволяет перенести реальную обработку пакетов PPP с терминального устройства L2.

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

L2TP позволяет также решить проблему расщепления групп (multilink hunt-group splitting). Расширение Multilink PPP [RFC1990] требует, чтобы все каналы, образующие композитное соединение, были связаны с одним сервером NAS. Благодаря возможности расширения сессий PPP за пределы точки физического завершения, протокол L2TP может использоваться для организации завершения всех каналов на одном устройстве NAS. Это позволяет организовать многоканальные соединения даже в тех случаях, когда используется множество физических устройств NAS.

В этом документе определен протокол управления для создания по запросам туннелей между парами узлов и выполнения связанной с этим инкапсуляции для мультиплексирования множества туннелируемых сессий PPP.

1.1 Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC2119].

1.2 Термины

Analog Channel — аналоговый канал

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

Attribute Value Pair (AVP) — пара «атрибут-значение»

Объединение переменного размера с уникальным атрибутом (Attribute), представленным целым числом и значением (Value), содержащим реальные данные, идентифицируемые атрибутом. Множество AVP образуют управляющие сообщения (Control Message), служащие для организации, поддержки и удаления туннелей.

Call — вызов

Соединение (или попытка такового) между удаленной системой (Remote System) и LAC. Примером может служить телефонный звонок через сеть PSTN. Соединение (входящее или исходящее) между Remote System и LAC приводит к созданию сессии L2TP в ранее созданном туннеле между LAC и LNS. (см. также Session, Incoming Call, Outgoing Call).

Called Number — вызываемый номер

Индикация принимающей вызов стороны (например, телефонный номер).

Calling Number — вызывающий номер

Индикация вызывающей стороны на приемной стороне (например, телефонный номер).

CHAP

Challenge Handshake Authentication Protocol [RFC1994] — протокол криптографически защищенной аутентификации PPP, в котором по линии не передается паролей в открытом виде.

Control Connection — управляющее соединение

Управляющее соединение существует в основной полосе туннеля и служит для организации, поддержки и разрыва сессий или самого туннеля.

Control Messages — управляющие сообщения

Управляющими сообщениями обмениваются между собой пары устройств LAC и LNS через существующий между ними туннель. Управляющие сообщения относятся к сессиям в данном туннеле и самому туннелю.

Digital Channel — цифровой канал

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

DSLAM

Модуль доступа по цифровым абонентским линиям (DSL3) — сетевое устройство, используемое для реализации сервиса DSL. Обычно представляет собой концентратор линий DSL в центральном офисе (CO) или местной станции.

Incoming Call — входящий вызов

Вызов, полученный LAC и туннелируемый на LNS (см. Call, Outgoing Call).

L2TP Access Concentrator (LAC) — концентратор доступа L2TP

Узел, который на одной стороне имеет конечные точки туннелей L2TP, а на другой стороне является партнером сетевого сервера L2TP (LNS). LAC размещается между LNS и удаленной системой, пересылая пакеты между ними. Пакеты от LAC к LNS требуют туннелирования L2TP в соответствии с данным документом. Соединение LAC с удаленной системой является локальным (см. Client LAC) или PPP-каналом.

L2TP Network Server (LNS) — сетевой сервер L2TP

Узел, который является конечной точкой туннеля L2TP и партнером LAC. LNS является логической точкой завершения сессии PPP, которая будет туннелироваться от удаленной системы через LAC.

Management Domain (MD) — домен управления

Сеть или сети, находящиеся под единым администрированием. Например, доменом управления для LNS может быть обслуживаемая им корпоративная сеть, а доменом управления LAC — ISP, который владеет управляет им.

Network Access Server (NAS) — сервер доступа в сеть

Устройство, обеспечивающее локальный сетевой доступ для пользователей через сеть удаленного доступа (например, PSTN). NAS может также служить в качестве LAC и/или LNS.

Outgoing Call — исходящий вызов

Вызов, организуемый LAC от имени LNS (см. Call, Incoming Call).

Peer — партнер

В контексте L2TP партнерами являются LAC или LNS. Партнером LAC является LNS и наоборот. В контексте PPP партнерами являются обе стороны соединения PPP.

POTS — телефонная сеть

Телефонная сеть общего пользования.

Remote System — удаленная система

Конечная система или маршрутизатор, подключенный к уделенной сети доступа (например, PSTN) и являющийся инициатором или адресатом вызова. Для обозначения удаленной системы используются также термины dial-up client или virtual dial-up client.

Session — сессия

Протокол L2TP ориентирован на соединения. LNS и LAC поддерживают состояние для каждого инициированного или принятого LAC вызова (Call). Сессия L2TP создается между LAC и LNS при организации сквозного соединения PPP между удаленной системой и LNS. Дейтаграммы, относящиеся к соединению PPP, передаются через туннель между LAC и LNS. Организованные сессии L2TP однозначно связаны с соответствующими вызовами (см. Call).

Tunnel — туннель

Туннели организуются между LAC и LNS. Туннель включает управляющее соединение и может также включать одну или множество сессий L2TP. Через туннель между LAC и LNS передаются инкапсулированные дейтаграммы PPP и управляющие сообщения.

Zero-Length Body (ZLB) Message — сообщение нулевого размера

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

2.0 Топология

На рисунке показан типовой случай использования L2TP. Целью является организация туннеля для кадров PPP между удаленной системой или клиентом LAC и LNS в домашней ЛВС.

                                                  [Домашняя ЛВС]
            [Клиент LAC]----------+                     |
                              ____|_____                +--[Хост]
                             |          |               |
               [LAC]---------| Internet |-----[LNS]-----+
                 |           |__________|               |
            _____|_____                                 :
           |           |
           |  PSTN     |
[Удален.]--|  Cloud    |
[система]  |           |                          [Домашняя ЛВС]
           |___________|                                |
                 |          ______________              +---[Хост]
                 |         |              |             |
               [LAC]-------| Frame Relay  |---[LNS]-----+
                           | или ATM      |             |
                           |______________|             :

Удаленная система инициирует организацию соединения PPP через телефонную сеть (PSTN Cloud) с LAC. После этого LAC туннелирует соединение PPP через Internet, Frame Relay или ATM Cloud до LNS, что обеспечивает доступ в домашнюю ЛВС. Удаленной системе предоставляется адрес из домашней ЛВС в результате согласования PPP NCP. Процедуры AAA4 доменом управления домашней ЛВС как для случая прямого подключения клиента к серверу доступа NAS.

Клиент LAC (хост с поддержкой L2TP) может также участвовать в создании туннеля в домашнюю ЛВС без привлечения отдельного LAC. В этом случае хост с программным клиентом LAC уже имеет соединение с публичной сетью Internet. Создается «виртуальное» соединение PPP и локальный клиент L2TP LAC создает туннель до LNS. Как и в предыдущем случае функции AAA будут обеспечиваться доменом управления домашней ЛВС.

3.0 Обзор протокола

L2TP использует два типа сообщений — управление и данные. Управляющие сообщения служат для организации, поддержки и удаления туннелей и вызовов. Сообщения с данными служат для инкапсуляции кадров PPP, передаваемых через туннель. Для управляющих сообщений используется надежный канал управления (Control Channel) в L2TP, обеспечивающий гарантированную доставку (см. параграф 5.1). При возникновении потери пакетов повторной передачи пакетов данных не производится.

+-------------------+
| Кадры PPP         |
+-------------------+    +-----------------------+
| Данные L2TP       |    | Управление L2TP       |
+-------------------+    +-----------------------+
| Канал данных L2TP |    | Канал управления L2TP |
| (без гарантий)    |    | (гарантиров. доставка)|
+------------------------------------------------+
|      Транспорт (UDP, FR, ATM и т. п.)          |
+------------------------------------------------+

Рисунок 3.0. Структура протокола L2TP.

На рисунке 3.0 показана передача кадров PPP и управляющих сообщений через каналы данных и управления L2TP. Кадры PPP передаются без гарантий доставки через канал данных с инкапсуляций сначала в L2TP, а затем в пакетный транспорт (UDP, Frame Relay, ATM и т. п.) Управляющие сообщения передаются через надежный канал управления L2TP в основной полосе того же пакетного транспорта.

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

Все значения помещаются в соответствующие поля и передаются в сетевом порядке (сначала старшие октеты).

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

Пакеты L2TP для управления и данных используют общий формат заголовков. Для необязательных полей пространство в пакете не используется при отсутствии поля. Отметим, что необязательные для пакетов данных поля Length, Ns и Nr являются обязательными в управляющих сообщениях.

Формат заголовков показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Tunnel ID           |           Session ID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Ns (opt)          |             Nr (opt)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Offset Size (opt)        |    Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3.1. Формат заголовков L2TP.

Флаг типа (T) указывает тип сообщения (0 для данных, 1 для управляющих сообщений).

Установленный флаг размера (L) говорит о присутствии поля Length. В управляющих сообщениях этот бит должен быть установлен.

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

Установленный флаг S говорит о наличии полей Ns и Nr. В управляющих сообщениях этот бит должен быть установлен.

Установленный флаг смещения (O) говорит о наличии поля Offset Size. В управляющих сообщениях этот бит должен быть сброшен (0).

Установленный флаг приоритета (P) означает, что этому сообщению с данными следует предоставить преимущество в локальных очередях и при передаче. Например, эхо-запросы LCP, используемые для сохранения живучести канала, следует передавать с установленным флагом приоритета. Если флаг не используется то при наличии локальной перегрузки сообщения keepalive могут теряться. Этот флаг используется только для сообщений с данными, а в управляющих сообщениях должно устанавливаться P = 0.

Поле Ver должно иметь значение 2, соответствующее версии сообщений с данными протокола L2TP, описанных в этом документе. Значение 1 зарезервировано для возможности детектирования пакетов L2F [RFC2341], которые могут приходить вперемешку с пакетами L2TP. Пакеты с неизвестным значением поля Ver должны отбрасываться.

Поле Length показывает общий размер сообщения в октетах.

Поле Tunnel ID служит идентификатором управляющего соединения. Туннели L2TP обозначаются идентификаторы с локальной значимостью. По этой причине один и тот же туннель может иметь на каждой стороне разные значения Tunnel ID. Поле Tunnel ID в сообщении предназначено для получателя, а не для отправителя. Значения Tunnel ID выбираются и информация о них передается в Assigned Tunnel ID AVP при создании туннеля.

Поле Session ID указывает идентификатор сессии в туннеле. Сессии L2TP обозначаются идентификаторами локальной значимости. Это означает, что одна и та же сессия может иметь разные значения Session ID на разных концах. Значение Session ID в каждом сообщении предназначено для получателя, а не отправителя. Значения Session ID выбираются и передаются в Assigned Session ID AVP при организации сессии.

Ns указывает порядковый номер передаваемого сообщения. Отсчет начинается с 0 и номер увеличивается на 1 для каждого последующего сообщения (модуль для нумерации 216). Дополнительная информация об использовании этого поля приводится в параграфах 5.8 и 5.4.

Nr показывает порядковый номер, который ожидается в следующем принятом управляющем сообщении. Таким образом, Nr представляет собой значение Ns из принятого последним без нарушения порядка сообщения плюс 1 (модуль для нумерации 216). В сообщениях с данными поле Nr является резервным и, при его использовании (как указано флагом S), должно игнорироваться на приемной стороне. Дополнительная информация об использовании этого поля приводится в параграфе 5.8.

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

3.2 Типы управляющих сообщений

Message Type AVP (см. параграф 4.4.1) определяет конкретный тип передаваемого сообщения. Напомним (параграф 3.1), что это относится только к управляющим сообщениям (сообщениям с T = 1).

Данный документ определяет перечисленные ниже типы сообщений (описание и применение сообщений в параграфах 6.1 — 6.14).

Поддержка управляющих соединений

0 (резерв)

1 (SCCRQ) Start-Control-Connection-Request

2 (SCCRP) Start-Control-Connection-Reply

3 (SCCCN) Start-Control-Connection-Connected

4 (StopCCN) Stop-Control-Connection-Notification

5 (резерв)

6 (HELLO) Hello

Управление соединениями

7 (OCRQ) Outgoing-Call-Request

8 (OCRP) Outgoing-Call-Reply

9 (OCCN) Outgoing-Call-Connected

10 (ICRQ) Incoming-Call-Request

11 (ICRP) Incoming-Call-Reply

12 (ICCN) Incoming-Call-Connected

13 (резерв)

14 (CDN) Call-Disconnect-Notify

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

15 (WEN) WAN-Error-Notify

Управление сеансами PPP

16 (SLI) Set-Link-Info

4.0 AVP для управляющих сообщений

Для обеспечения максимальной расширяемости с сохранением интероперабельности в L2TP используется однотипное представление типов и сообщений. Это представление называется AVP5 и используется в оставшейся части документа.

4.1 Формат AVP

Каждая пара AVP представляется в виде:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H| rsvd  |      Length       |           Vendor ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Attribute Type        |        Attribute Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  [до размера, заданного Length]...                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Первые 6 битов задают маску, описывающую общие атрибуты AVP.

В этом документе определены два бита маски, а прочие оставлены для будущих расширений. Резервные биты должны устанавливаться в 0. AVP, полученные с установленными в 1 резервными битами маски, должны трактоваться, как нераспознанные AVP.

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

Бит H7. Указывает на сокрытие данных в поле Attribute Value пары AVP. Это свойство может использоваться для предотвращения данных, которые не следует раскрывать (например, пользовательских паролей) в открытом виде внутри AVP. Процедура сокрытия AVP описана в параграфе 4.3.

Length. Задает число октетов (включая поле Overall Length и маску) в данной AVP. Значение Length можно рассчитать, добавив 6 к размеру поля Attribute Value в октетах. Само поле имеет размер 10 битов, что позволяет представлять поля размером до 1023 октетов в одной AVP. Минимальное значение поля Length для AVP составляет 6. В этом случае поле Attribute Value отсутствует.

Vendor ID. Значение из выделенного агентством IANA реестра SMI Network Management Private Enterprise Codes [RFC1700]. Значение 0, соответствующее принятым IETF атрибутам, используется для всех AVP, определенных в данном документе. Любой производитель, желающий реализовать свои расширения L2TP, может использовать свое значение Vendor ID вместе с приватными значениями Attribute, что гарантирует отсутствие конфликтов с расширениями других производителей и будущими расширениями IETF. Отметим, что 16 битов поля Vendor ID ограничивают число идентификаторов значением 65 535.

Attribute Type. Двухоктетное значение с уникальной интерпретацией среди всех AVP для данного Vendor ID.

Attribute Value. Реальное значение атрибута, заданного полями Vendor ID и Attribute Type. Это поле следует непосредственно за полем Attribute Type и включает число октетов до смещения, заданного полем Length (т. е., Length — 6 октетов заголовка). При Length = 6 это поле отсутствует.

4.2 Обязательные AVP

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

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

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

4.3 Сокрытие значений атрибутов AVP

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

Флаг H должен устанавливаться только в тех случаях, когда LAC и LNS известен общий секрет. Это тот же секрет, который служит для аутентификации туннеля (параграф 5.1.1). Если бит H установлен в любом из AVP данного управляющего сообщения, в этом сообщении должна также присутствовать Random Vector AVP и эта пара должна размещаться перед первым AVP с H = 1.

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length of Original Value    |   Original Attribute Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...                          |             Padding ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length of Original Attribute Value — это поле указывает размер исходного значения скрываемого атрибута в октетах. Это значение требуется сохранять, поскольку размер меняется в результате заполнения Padding.

Original Attribute Value — исходное значение скрываемого атрибута.

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

Для маскировки размера скрываемых данных в субформате может использоваться показанное выше заполнение. Поле Padding не учитывается в Length of Original Attribute Value, но меняет размер получаемой в результате AVP. Например, если скрывается 4-октетное значение атрибута, поле размера нескрытой AVP будет иметь значение 10 (6 + 4). После сокрытия размер AVP будет равен 6 + размер Attribute Value + размер Length of Original Attribute Value + Padding. Таким образом при 12 октетах заполнения размер AVP будет 6 + 4 + 2 + 12 = 24 октета.

После этого определяется хэш MD5 для конкатенации:

2 октета номера атрибута из AVP;

разделяемый секрет;

случайный вектор произвольной длины.

Используемый в этом хэше случайный вектор передается в поле Random Vector AVP. Эта пара Random Vector AVP должна помещаться отправителем в сообщение впереди всех скрываемых AVP. Один и тот же случайный вектор может использоваться для множества AVP в одном сообщении. При использовании разных векторов для сокрытия последовательных AVP новый Random Vector AVP должен помещаться перед первой AVP, к которой он будет применяться.

Хэш MD5 используется в операции XOR применительно к первым 16 (или меньше) октетам Hidden AVP Subformat и результат помещается в поле Attribute Value скрываемой пары Hidden AVP. Если размер Hidden AVP Subformat меньше 16 октетов, субформат преобразуется, как будто поле Attribute Value дополнено до 16 октетов перед операцией XOR, но меняются только октеты, реально присутствующие в Subformat , а размер AVP не меняется.

Если размер Subformat превышает 16 октетов, рассчитывается второе значение MD5 для потока октетов, состоящего из разделяемого секрета, за которым следует результат первой операции XOR. Полученное значение используется для операции XOR с вторым сегментом из 16 (или меньше) октетов Subformat и помещается в соответствующие октеты поля Value пары Hidden AVP.

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

Метод сокрытия был взят из RFC 2138 [RFC2138], заимствовавшего его, в свою очередь из раздела Mixing in the Plaintext книги Network Security, авторами которой являются Kaufman, Perlman и Speciner [KPS]. Ниже приведено подробное разъяснение этого метода.

Возьмем разделяемый секрет S, случайный вектор RV и значение атрибута AV. Разделим поле значения на 16-октетные блоки p1, p2 и т. д., дополнив при необходимости последний блок случайными данными до размера 16 октетов. Возьмем шифрованные блоки c(1), c(2) и т. д. Определим также промежуточные значения b1, b2 и т. д.

          b1 = MD5(AV + S + RV)   c(1) = p1 xor b1
          b2 = MD5(S  + c(1))     c(2) = p2 xor b2
                      .                       .
                      .                       .
                      .                       .
          bi = MD5(S  + c(i-1))   c(i) = pi xor bi

String будет содержать c(1)+c(2)+…+c(i), где + обозначает конкатенацию.

При получении случайный вектор берется из последней пары Random Vector AVP в сообщении, расположенной перед раскрываемой AVP. Описанная выше процедура выполняется в обратном направлении для восстановления исходного значения.

4.4 Описание AVP

В последующих параграфах рассматриваются все L2TP AVP, определяемые в данном документе.

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

4.4.1 AVP, применимые для всех управляющих сообщений

Message Type (все сообщения)

Message Type AVP (Attribute Type 0) идентифицирует управляющее сообщение и определяет контекст, в котором будет определяться точный смысл последующих AVP.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Message Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message Type представляет собой 2-октетное целое число без знака.

Message Type AVP должна быть первой AVP в сообщении, следуя непосредственно после заголовка управляющего сообщения (определен в параграфе 3.1). Список определенных типов управляющих сообщений и их идентификаторы приведены в параграфе 3.2.

Бит обязательности (M) в Message Type AVP имеет специальное значение. Он относится не к данной AVP, как обычно, а ко всему управляющему сообщению. Таким образом, если в Message Type AVP установлен бит M а тип сообщения не известен реализации, туннель должен закрываться. Если бит M сброшен, реализация может игнорировать сообщение неизвестного типа. Флаг M должен устанавливаться для всех типов сообщений, определенных в этом документе. Эта AVP не может быть скрыта (бит H должен быть сброшен). Поле Length для этой AVP имеет значение 8.

Random Vector (все сообщения)

Random Vector AVP (Attribute Type 36) используется для того, чтобы разрешить сокрытие Attribute Value в AVP.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random Octet String ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Random Octet String может иметь произвольный размер, хотя рекомендуется использовать случайные векторы не короче 16 октетов. Строка содержит случайный вектор, используемый при расчете значения MD5 для извлечения или сокрытия значения Attribute Value в AVP (см. параграф 4.2).

В сообщении может присутствовать несколько Random Vector AVP. В этом случае для скрытых AVP используется ближайшая предшествующая пара Random Vector AVP. Данная AVP должна приедшествовать первой AVP с установленным битом H.

Бит M для данной AVP должен иметь значение 1. Такую AVP недопустимо скрывать (бит H должен иметь значение 0). Поле Length в данной AVP имеет значение размера Random Octet String + 6.

4.4.2 Коды результатов и ошибок

Result Code (CDN, StopCCN)

Result Code AVP (Attribute Type 1) указывает причину разрыва управляющего канала или сессии.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Result Code          |        Error Code (opt)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Error Message (opt) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Result Code представляет собой 2-октетное целое число без знака. Необязательное поле Error Code также является 2-октетным целым числом без знака. За полем Error Code может следовать необязательное поле Error Message. Присутствие полей Error Code и Error Message указаывается полем AVP Length. Поле Error Message содержит произвольную строку, обеспечивающую дополнительный (понятный человеку) текст, связанный с ошибкой. Текст для человека во всех сообщениях об ошибках должен задаваться в кодировке UTF-8 с использованием принятого по умолчанию языка (Default Language) [RFC2277].

Такие AVP недопустимо скрывать (бит H должен иметь значение 0). Бит M для таких AVP должен иметь значение 1. Поле Length имеет значение 8 при отсутствии Error Code и Error Message, 10 при наличии Error Code без Error Message и 10 + размер Error Message, если присутствуют код и сообщение об ошибке.

Определенные для сообщений StopCCN значения Result Code включают:

0 — резерв

1 — запрос общего типа для сброса управляющего соединения;

2 — типовая ошибка, проблему указывает Error Code;

3 — управляющий канал уже существует;

4 — запрашивающий не имеет полномочий на организацию управляющего канала;

5 — версия протокола у запрашивающего не поддерживает значение Error Code более новой версии;

6 — запрашивающий будет отключен (shut down);

7 — ошибка машины конечных состояний.

Определенные для сообщений CDN значения Result Code включают:

0 — резерв

1 — соединение разорвано в результате потери несущей;

2 — соединение разорвано по причине, указанной кодом ошибки;

3 — соединение разорвано административными мерами;

4 — отказ при соединении по причине недоступности (временно);

5 — отказ при соединении по причине недоступности (постоянная ошибка);

6 — некорректный адресат;

7 — отказ в соединении по причине отсутствия несущей;

8 — отказ в соединении по причине занятости линии;

9 — отказ в соединении по причине слабого сигнала вызова (dial tone);

10 — соединение не было организовано в течение интервала, отведенного устройством LAC;

11 — соединение организовано, но не найдено подходящего кадрирования.

Значения Error Code, определенные ниже, относятся не к каким-либо ошибкам для конкретных запросов L2TP, а к ошибкам протокола или формата сообщений. Если отклик L2TP указывает в своем Result Code ошибку общего типа, следует проверить значение кода General Error для определения причины ошибки. Ниже перечислены определенные в настоящее время значения кодов General Error и краткие описания.

0 — нет ошибок;

1 — нет управляющего соединения для данной пары LAC — LNS;

2 — некорректный размер;

3 — значение одного из полей выходит за допустимые пределы или резервное поле отлично от нуля;

4 — в настоящее время недостаточно ресурсов для обработки операции;

5 — значение Session ID некорректно в данном контексте;

6 — ошибка общего типа, специфическая для производителя LAC;

7 — повторите попытку; если устройству LAC известны другие возможные адресаты LNS, ему следует пытаться использовать один из них; это может служить руководством для LAC, работающего на основе политики LNS (например, наличие множества групп multilink PPP);

8 — сессия или туннель разорваны по причине получения неизвестной AVP с установленным флагом M (см. параграф 4.2). В сообщение об ошибке следует включать атрибут вызвавшей проблему AVP в (понятном человеку) текстовом формате.

При использовании кода General Error 6 следует включать дополнительную информацию об ошибке в поле Error Message.

4.4.3 AVP для контроля управляющих сообщений

Protocol Version (SCCRP, SCCRQ)

Protocol Version AVP (Attribute Type 2) показывает версию протокола L2TP у отправителя.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Ver      |     Rev       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Ver размером 1 октет содержит целое число без знака 1. Поле Rev имеет размер 1 октет и содержит целое число без знака 0. Это указывает протокол L2TP версии 1, вариант 0. Отметим, что это не то же самое, что номер версии, указываемый в заголовке каждого сообщения.

Данную AVP недопустимо скрывать (бит H должен иметь значение 0). Бит M для данной AVP должен иметь значение 1. Поле Length в данной AVP имеет значение 8.

Framing Capabilities (SCCRP, SCCRQ)

Framing Capabilities AVP (Attribute Type 3) показывает партнеру типы кадрирования, поддерживаемые или запрашиваемые отправителем.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Резерв для будущих типов кадрирования              |A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Attribute Value является 32-битовой маской, в которой определены 2 бита. Бит A указывает поддержку асинхронного кадрирования, бит S — поддержку синхронного.

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

Данная AVP может быть скрытой (H = 1). Бит M в данной AVP должен быть установлен (1). Поле Length (без сокрытия) имеет значение 10.

Bearer Capabilities (SCCRP, SCCRQ)

Bearer Capabilities AVP (Attribute Type 4) показывает партнеру типы устройств, поддерживаемых аппаратными интерфейсами отправителя для исходящих вызовов.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Резерв для будущих типов                   |A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Attribute Value является 32-битовой маской, в которой определены 2 бита. Бит A указывает поддержку аналогового доступа, бит D — поддержку цифрового доступа.

Устройствам LNS не следует запрашивать исходящих вызовов, которые задают Bearer Type AVP для типов устройств, не анонсированных в Bearer Capabilities AVP, полученных от LAC при организации управляющего соединения. При возникновении такой попытки она будет завершаться отказом.

Данная AVP должна присутствовать, если отправитель может организовывать исходящие вызовы по запросам.

Отметим, что устройство LNS, которое не может работать в качестве LAC, не будет также поддерживать аппаратных компонент для обслуживания входящих или исходящих вызовов и ему следует устанавливать нулевые значения битов A и D в данной AVP или совсем не использовать таких AVP. Устройству LNS, которое может служить LAC и организовывать исходящие вызовы, следует устанавливать биты A и D по своим возможностям. Присутствие этого сообщения не гарантирует организации исходящего вызова по запросу отправителя, а лишь указывает на физическую возможность организации таких вызовов.

Данная AVP может быть скрытой (бит H может быть установлен). Бит M для этой AVP должен иметь значение 1. Поле Length (до сокрытия) имеет значение 10.

Tie Breaker (SCCRQ)

Tie Breaker AVP (Attribute Type 5) показывает желание отправителя использовать только один туннель между данными LAC и LNS.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Tie Break Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                 ...(64 bits)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Tie Breaker Value представляет собой 8-октетное значение, которое служит для выбора одного туннеля, когда оба устройства LAC и LNS запрашивают туннельные соединения. Получатель SCCRQ должен проверить свою передачу SCCRQ отправителю и, при наличии таковой, сравнить значения Tie Breaker. По результатам сравнения выбирается меньшее из двух значений и соответствующий ему туннель должен быть сброшен без уведомления. Если значения совпадают, обе стороны должны сбросить свои туннели.

Если на получившей SCCRQ стороне нет значения Tie Breaker, «выигрывает» инициатор отправки Tie Breaker AVP. Если ни одна из сторон не использовала SCCRQ, организуются два раздельных туннеля.

Данную AVP недопустимо скрывать (бит H должен иметь значение 0). Бит M для данной AVP должен быть сброшен (0). Поле Length в данной AVP имеет значение 14.

Firmware Revision (SCCRP, SCCRQ)

Firmware Revision AVP (Attribute Type 6) показывает версию программного кода на устройстве.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Firmware Revision представляет собой 2-октетное целое число без знака, формат представления версии определяется производителем.

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

Данная AVP может быть скрытой (бит H может быть установлен). Бит M для этой AVP должен иметь значение 0. Поле Length (до сокрытия) имеет значение 8.

Host Name (SCCRP, SCCRQ)

Host Name AVP (Attribute Type 7) указывает имя передавшего атрибут устройства LAC или LNS.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Host Name ... (произвольное число октетов)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Host Name может иметь произвольный размер, но должно быть не короче 1 октета.

Следует использовать в этом поле по возможности уникальное имя. Для хостов, участвующих в DNS [RFC1034], подойдет полное доменное имя хоста.

Эту AVP недопустимо скрывать (бит H должен иметь значение 0). Бит M для данной AVP должен быть установлен (1). Поле Length в этой AVP равно размеру Host Name + 6.

Vendor Name (SCCRP, SCCRQ)

Vendor Name AVP (Attribute Type 8) указывает имя производителя (возможно, для человека), описывающее тип используемого устройства LAC или LNS.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Vendor Name ...(произвольное число октетов)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Vendor Name представляет имя производителя в строке символов. Предназначенный для людей текст должен использовать кодировку UTF-8 для принятого по умолчанию языка (Default Language [RFC2277]).

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0). Поле Length в этой AVP равно размеру Vendor Name + 6.

Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)

Assigned Tunnel ID AVP (Attribute Type 9) представляет идентификатор, который будет присвоен данному туннелю отправителем.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Assigned Tunnel ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Assigned Tunnel ID представляет собой 2-октетное целое число без знака, отличное от 0.

Assigned Tunnel ID AVP организует значение, используемое для мультиплексирования и демультиплексирования туннелей между LNS и LAC. Партнер L2TP должен помещать это значение в поле заголовка Tunnel ID всех сообщений, передаваемых через данный туннель. До получения от партнера Assigned Tunnel ID AVP управляющие сообщения должны передаваться в туннель с Tunnel ID = 0 в заголовках.

В управляющем сообщении StopCCN пара Assigned Tunnel ID AVP должна совпадать с Assigned Tunnel ID AVP, переданной изначально принимающему партнеру, что позволяет идентифицировать туннель даже при получении StopCCN раньше, чем Assigned Tunnel ID AVP.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length в этой AVP (до сокрытия) имеет значение 8.

Receive Window Size (SCCRQ, SCCRP)

Receive Window Size AVP (Attribute Type 10) указывает размер приемного окна, предлагаемый удаленным партнером.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Window Size           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Window Size представляет собой 2-октетное целое число без знака.

В отсутствии информации партнер должен устанавливать Window Size = 4 для своего окна передачи. Удаленный партнер может передать указанное размером окна число управляющих сообщений без ожидания подтверждений.

Эту AVP недопустимо скрывать (бит H должен иметь значение 0). Бит M для данной AVP должен быть установлен (1). Length = 8.

Challenge (SCCRP, SCCRQ)

Challenge AVP (Attribute Type 11) показывает желание партнера аутентифицировать конечные точки туннеля с использованием механизма в стиле CHAP.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Challenge ... (произвольное число октетов)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Challenge представляет собой один или множество октетов случайных денных.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP равно размеру Challenge + 6.

Challenge Response (SCCCN, SCCRP)

Response AVP (Attribute Type 13) предоставляет отклик на полученный вызов.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Response ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                              ... (16 octets)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Response имеет размер 16 октетов и представляет собой отклик на вызов в стиле CHAP [RFC1994].

Данная AVP должна присутствовать в SCCRP или SCCCN, если в предшествующем SCCRQ или SCCRP был получен вызов. В качестве значения ID при расчете отклика CHAP используется значение Message Type AVP для данного сообщения (2 для SCCRP или 3 для SCCCN).

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 22.

4.4.4 AVP для управления вызовами

Q.931 Cause Code (CDN)

Q.931 Cause Code AVP (Attribute Type 12) используется для предоставления дополнительной информации в случаях незапрошенного разрыва соединений.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Cause Code           |   Cause Msg   | Advisory Msg...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В поле Cause Code возвращается код Q.931 Cause code, а в Cause Msg код сообщения Q.931 (например, DISCONNECT), связанного с Cause Code. Оба значения представляются в естественной кодировке ITU [DSS1]. Дополнительный ASCII-текст в поле Advisory Message (его присутствие указывается значением поля AVP Length) служит для дополнительного разъяснения причины разрыва соединения.

Эту AVP недопустимо скрывать (бит H должен иметь значение 0). Бит M для данной AVP должен быть установлен (1). Поле Length в этой AVP равно размеру Advisory Message + 9.

Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)

Assigned Session ID AVP (Attribute Type 14) представляет идентификатор, выделяемый для данной сессии отправителем.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Assigned Session ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Assigned Session ID представляет собой 2-октетное целое число без знака, отличное от 0.

Assigned Session ID AVP обеспечивает идентификатор, служащий для мультиплексирования и демультиплексирования данных, направляемых через туннель между LNS и LAC. Партнер L2TP должен помещать это значение в поле заголовка Session ID всех сообщений, которые будут передаваться через туннель во время существования данной сессии. До получения от партнера Assigned Session ID AVP, все управляющие сообщения должны передаваться ему с Session ID = 0 в заголовках.

В управляющем сообщении CDN используется та же самая Assigned Session ID AVP, которая ранее была отправлена принимающему партнеру, что позволяет идентифицировать подходящий туннель даже в тех случаях, когда CDN передается до получения Assigned Session ID.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 8.

Call Serial Number (ICRQ, OCRQ)

Call Serial Number AVP (Attribute Type 15) показывает идентификатор, присвоенный соединению LAC или LNS.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Call Serial Number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Call Serial Number имеет размер 32 бита.

Значение Call Serial Number предназначено для администраторов на обеих сторонах туннеля и позволяет идентифицировать соединения при поиске неисправностей. Значения Call Serial Number следует устанавливать в порядке возрастания и обеспечивать долговременную уникальность нумерации для всех связанных между собой устройств LNS и LAC.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 10.

Minimum BPS (OCRQ)

Minimum BPS AVP (Attribute Type 16) показывает минимально допустимую скорость в линии для данного вызова.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Minimum BPS                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Minimum BPS представляет собой 32-битовое значение, указывающее скорость в бит/сек.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 10.

Maximum BPS (OCRQ)

Maximum BPS AVP (Attribute Type 17) показывает максимально допустимую скорость в линии для этого вызова.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Maximum BPS                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Minimum BPS представляет собой 32-битовое значение, указывающее скорость в бит/сек.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 10.

Bearer Type (ICRQ, OCRQ)

Bearer Type AVP (Attribute Type 18) представляет тип входящего или исходящего вызова.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           резерв для будущих типов вызовов                |A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Bearer Type представляет собой 32-битовую маску, которая показывает свойства (ICRQ) или требования (OCRQ) для вызова. Установленный бит A показывает, что вызов относится к аналоговым каналам, бит D — к цифровым. Установка обоих флагов сразу показывает, что вызовы не различаются или могут размещаться на обоих типах каналов.

Биты поля Value данной AVP должны устанавливаться устройством LNS для OCRQ только в тех случаях, когда они были установлены в Bearer Capabilities AVP, полученной от LAC при организации управляющего соединения.

В ICRQ можно не устанавливать ни один из битов A и D. Это будет говорить о том, что вызов принимается не по физическому каналу (например, если LAC и PPP размещаются в одной подсистеме).

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 10.

Framing Type (ICCN, OCCN, OCRQ)

Framing Type AVP (Attribute Type 19) представляет тип кадрирования для входящих или исходящих вызовов.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           резерв для будущих типов кадрирования           |A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Framing Type представляет собой 32-битовую маску, которая показывает тип кадрирования PPP, запрашиваемый для OCRQ, или согласованный тип кадрирования PPP для OCCN или ICCN. Тип кадрирования может служить модулю PPP на устройстве LNS индикацией опций для использования при согласовании LCP [RFC1662].

Бит A показывает асинхронное кадрирование, бит S — синхронное. Для OCRQ могут устанавливаться оба бита, указывая возможность использования любого ттипа кадрирования.

Биты поля Value данной AVP должны устанавливаться устройством LNS для OCRQ только в тех случаях, когда они были установлены в Framing Capabilities AVP, полученной от LAC при организации управляющего соединения.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 10.

Called Number (ICRQ, OCRQ)

Called Number AVP (Attribute Type 21) показывает телефонный номер для звонка в OCRQ или номер звонящего в ICRQ.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Called Number... (произвольное число октетов)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Called Number представляет собой строку ASCII. Для согласования интерпретации значений может потребоваться контакт между администраторами LAC и LNS.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер Called Number.

Calling Number (ICRQ)

Calling Number AVP (Attribute Type 22) показывает телефонный номер вызывающей стороны при входящем звонке.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Calling Number... (произвольное число октетов)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Calling Number представляет собой строку ASCII. Для согласования интерпретации значений может потребоваться контакт между администраторами LAC и LNS.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер Calling Number.

Sub-Address (ICRQ, OCRQ)

Sub-Address AVP (Attribute Type 23) представляет дополнительные сведения о звонящем.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sub-Address ... (произвольное число октетов)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Sub-Address представляет собой строку ASCII. Для согласования интерпретации значений может потребоваться контакт между администраторами LAC и LNS.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер Sub-Address.

(Tx) Connect Speed (ICCN, OCCN)

(Tx) Connect Speed BPS AVP (Attribute Type 24) показывает скорость среды, выбранной для попытки соединения.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             BPS                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле BPS представляет собой 4-октетное значение, задающее скорость в бит/сек.

При наличии необязательной Rx Connect Speed AVP значение данной AVP представляет скорость передачи с точки зрения LAC (т. е.. потока данных от LAC к удаленной системе). При отсутствии Rx Connect Speed скорость соединения между удаленной системой и LAC предполагается одинаковой для обоих направлений и представленной данной AVP.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 10.

Rx Connect Speed (ICCN, OCCN)

Rx Connect Speed AVP (Attribute Type 38) представляет скорость соединения с точки зрения LAC (поток данных от удаленной системы к LAC).

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           BPS (H)             |            BPS (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле BPS представляет собой 4-октетное значение, задающее скорость в бит/сек.

Наличие данной AVP предполагает возможную асимметрию соединения в части скорости.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 10.

Physical Channel ID (ICRQ, OCRP)

Physical Channel ID AVP (Attribute Type 25) представляет номер физического канала, используемого для вызова (зависит от производителя).

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Physical Channel ID представляет собой 4-октетное значение, которое может использоваться только в целях протоколирования.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 10.

Private Group ID (ICCN)

Private Group ID AVP (Attribute Type 37) используется LAC для индикации связи данного вызова с конкретной группой заказчиков.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Private Group ID ... (произвольное число октетов)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Private Group ID представляет собой строку октетов произвольной длины.

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

Private Group ID представляет собой строку, соответствующую таблице в LNS, определяющей характеристики указанной группы. LAC может определить Private Group ID из отклика RADIUS, локальной конфигурации или иных источников.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер Private Group ID.

Sequencing Required (ICCN, OCCN)

Sequencing Required AVP (Attribute Type 39) показывает устройству LNS, что в канале данных всегда должны присутствовать порядковые номера.

Данная AVP не имеет поля Attribute Value.

Сокрытие данной AVP недопустимо (H = 0). Бит M для данной AVP должен быть установлен (1), Length = 6.

4.4.5 AVP для Proxy LCP и аутентификации

LAC может иметь отвеченные вызовы и согласованные LCP с удаленной системой, которые могут служить для ее идентификации. В этом случае могут использоваться рассмотренные ниже AVP, служащие для индикации свойств соединения, запрошенных изначально удаленной системой, свойств, согласованных удаленной системой и LAC, а также аутентификационной информации PPP, переданной и полученной LAC. Эта информация может использоваться для инициирования PPP LCP и аутентификации на LNS, позволяющей PPP продолжить работу без повторного согласования LCP. Отметим, что политика LNS может требовать дополнительного согласования LCP и/или аутентификации, если LAC не является доверенным.

Initial Received LCP CONFREQ (ICCN)

Initial Received LCP CONFREQ AVP (Attribute Type 26) предоставляет LNS значение Initial CONFREQ, полученное LAC от партнера PPP.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | LCP CONFREQ... (произвольное число октетов)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле LCP CONFREQ содержит копию тела первого CONFREQ, начиная с первой опции в теле сообщения LCP.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер CONFREQ.

Last Sent LCP CONFREQ (ICCN)

Last Sent LCP CONFREQ AVP (Attribute Type 27) предоставляет LNS значение Last CONFREQ, переданное LAC партнеру PPP.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | LCP CONFREQ... (произвольное число октетов)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле LCP CONFREQ содержит копию тела последнего CONFREQ, переданного клиенту для завершения согласования LCP, начиная с первой опции в теле сообщения LCP.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер CONFREQ.

Last Received LCP CONFREQ (ICCN)

Last Received LCP CONFREQ AVP (Attribute Type 28) предоставляет LNS значение Last CONFREQ, полученное LAC от партнера PPP.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | LCP CONFREQ... (произвольное число октетов)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле LCP CONFREQ содержит копию тела последнего CONFREQ, полученного от клиента для завершения согласования LCP, начиная с первой опции в теле сообщения LCP.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер CONFREQ.

Proxy Authen Type (ICCN)

Proxy Authen Type AVP (Attribute Type 29) определяет, следует ли пользоваться прокси-аутентификацией.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Authen Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Authen Type представляет собой 2-октетное целое число без знака.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0). Поле Length (до сокрытия) в этой AVP имеет значение 8.

Определены следующие значения Authen Type:

0 — резерв;

1 — обмен username/password в форме текста;

2 — PPP CHAP;

3 — PPP PAP;

4 — без аутентификации;

5 — Microsoft CHAP версии 1 (MSCHAPv1).

Данная AVP должна присутствовать, если используется прокси-аутентификация. При отсутствии аднной пары предполагается, что данный партнер не может выполнять прокси-аутентификацию — это требует перезапуска фазы аутентификации на устройстве LNS, если клиент уже вошел в эту фазу взаимодействия с LAC (может определяться Proxy LCP AVP при ее наличии).

Для каждого типа аутентификации далее следуют соответствующие AVP.

Proxy Authen Name (ICCN)

Proxy Authen Name AVP (Attribute Type 30) указывет имя аутентифицирующего клиента при использовании прокси-аутентификации.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Authen Name... (произвольное число октетов)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Данная AVP должна присутствовать в сообщениях, включающих Proxy Authen Type AVP со значениями 1, 2, 3, 5. Может оказаться желательным сокрытие данной AVP, поскольку имя указывается открытым текстом.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер текстовой строки с именем.

Proxy Authen Challenge (ICCN)

Proxy Authen Challenge AVP (Attribute Type 31) указывает запрос (challenge), переданный LAC партнеру PPP при использовании прокси-аутентификации.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Challenge... (произвольное число октетов)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Challenge представляет собой строку из одного или множества октетов.

Данная AVP должна присутствовать для Proxy Authen типов 2 и 5. Поле Challenge содержит значение CHAP challenge, представленное клиенту устройством LAC.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер Challenge.

Proxy Authen ID (ICCN)

Proxy Authen ID AVP (Attribute Type 32) указывает идентификатор для аутентификации PPP, которая была начата между LAC и партнером PPP при использовании прокси-аутентификации.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    резерв     |      ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ID представляет собой 2-октетное целое число без знака; старший октет должен иметь значение 0.

Proxy Authen ID AVP должна присутствовать для Proxy Authen типов 2, 3 и 5. Для типов 2 и 5 поле ID содержит значение ID, представленное клиенту LAC в своем Challenge, для типа 3 — значение Identifier в Authenticate-Request.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0).

Proxy Authen Response (ICCN)

Proxy Authen Response AVP (Attribute Type 33) указывает отклик PPP Authentication, полученный LAC от партнера PPP при использовании прокси-аутентификации.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Response... (произвольное число октетов)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Response представляет собой строку октетов.

Данная AVP должна присутствовать для Proxy Authen типов 1, 2, 3, 5. Поле Response содержит клиентский отклик на вызов (challenge). Для типов 2 и 5 это поле указывает значение отклика, полученное LAC, для типов 1 и 3 — пароль (в открытом виде), полученный LAC от клиента. При использовании текстовых паролей рекомендуется скрывать данную AVP.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть сброшен (0). Поле Length (до сокрытия) в этой AVP имеет значение 6 + размер Response.

4.4.6 AVP для статуса вызовов

Call Errors (WEN)

Call Errors AVP (Attribute Type 34) используется LAC для передачи информации об ошибках устройству LNS.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |        CRC Errors (H)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         CRC Errors (L)        |        Framing Errors (H)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Framing Errors (L)    |        Hardware Overruns (H)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Hardware Overruns (L) |        Buffer Overruns (H)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Buffer Overruns  (L)  |        Time-out Errors (H)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Time-out Errors (L)   |        Alignment Errors (H)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Alignment Errors (L)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ниже перечислены определенные к настоящему моменту поля.

Reserved — не используется и должно иметь значение 0;

CRC Errors — число кадрой PPP с ошибками CRC, принятых с момента организации соединения;

Framing Errors — число принятых пакетов PPP с недопустимым кадрированием;

Hardware Overruns — число фактов переполнения приемного буфера с момента организации соединения;

Buffer Overruns — число фактов переполнения буфера с момента организации соединения;

Time-out Errors — число тайм-аутов с момента организации соединения;

Alignment Errors — число ошибок выравнивания с момента организации соединения.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 32.

ACCM (SLI)

ACCM AVP (Attribute Type 35) используется LNS для информирования LAC о параметрах ACCM согласованных с партнером PPP.

Формат поля Attribute Value для данной AVP показан ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Reserved             |    Send ACCM (H)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Send ACCM   (L)      |    Receive ACCM (H)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Receive ACCM  (L)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля Send ACCM и Receive ACCM имеют размер 4 октета каждое, а перед ними размещается 2-оетктное резервное поле. Значение Send ACCM устройству LAC следует использовать для обработки пакетов, передаваемых в соединение. Значение Receive ACCM устройству LAC следует использовать для обработки пакетов, принимаемых из соединения. По умолчанию LAC для обоих полей использует значение 0xFFFFFFFF. Устройствам LAC следует пользоваться значениями этих полей, если у них нет конкретной конфигурационной информации, указывающей, что запрошенную маску требуется изменить для выполнения операции.

Эта AVP может быть скрытой (бит H может быть установлен). Бит M для данной AVP должен быть установлен (1). Поле Length (до сокрытия) в этой AVP имеет значение 16.

5.0 Работа протокола

Действия по организации туннелирования сессии PPP с использованием L2TP включают два этапа: (1) организация управляющего соединения (Control Connection) для туннеля и (2) организация сессии по входящему или исходящему запросу на соединение. Туннель и соответствующее управляющее соединение должны быть организованы до того, как будет инициирован входящий или исходящий вызов. Сессия L2TP должна быть организована до того, как L2TP начнет туннелировать кадры PP. В одном туннеле может быть организовано множество сессий, а между парой LAC и LNS может существовать множество туннелей.

                          +-----+                               +-----+
                          |     |~~~~~~~~~~Туннель L2TP~~~~~~~~~|     |
                          | LAC |                               | LNS |
                          |     #####Управляющее соединение######     |
 [Удален.]                |     |                               |     |
 [система]-----Вызов---------*============Сессия L2TP==============*  |
   PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                          |     |                               |     |
 [Удален.]                |     |                               |     |
 [система]-----Вызов---------*============Сессия L2TP==============*  |
   PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                          |     |                               |     |
                          |     |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|     |
                          +-----+                               +-----+

Рисунок 5.1. Туннелирование PPP

5.1 Организация управляющего соединения

Control Connection представляет собой начальное соединение, которое должно быть организовано между LAC и LNS до того, как можно будет организовать какие-либо сессии. Организация управляющего соединения включает обеспечение идентификации партнера, определение версии L2TP у него, кадрирование, согласование возможностей и т. п.

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

      LAC или LNS  LAC или LNS
      -----------  ----------
      SCCRQ -> 
                   <- SCCRP
      SCCCN ->
                   <- ZLB ACK

Сообщение ZLB ACK передается в тех случаях, когда в очереди для данного партнера нет других сообщений.

5.1.1 Аутентификация туннеля

L2TP включает простой, необязательный механизм (похожий на CHAP [RFC1994]) аутентификации туннеля в процессе организации управляющего соединения. Если LAC или LNS желает проверить идентичность контактирующего с ним партнера в сообщение SCCRQ или SCCRP включается Challenge AVP. При получении Challenge AVP в SCCRQ или SCCRP, должна быть передана Challenge Response AVP в SCCRP или SCCCN, соответственно. Если полученный отклик не соответствует ожидаемому от партнера, организация туннеля должна блокироваться.

Для участия в аутентификации туннеля устройства LAC и LNS должны знать общий секрет. Это тот же секрет, который применяется для сокрытия AVP (см. параграф 4.3). Описание AVP для запросов и откликов дано в параграфе 4.4.3.

5.2 Организация сессии

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

5.2.1 Организация входящего вызова

Организация сессии состоит из обмена тремя сообщениями, как показано ниже.

      LAC         LNS
      ---         ---
      (Обнаружен вызов)

      ICRQ ->
               <- ICRP
      ICCN ->
               <- ZLB ACK

Сообщение ZLB ACK передается в тех случаях, когда в очереди для данного партнера нет других сообщений.

5.2.2 Организация исходящего вызова

Организация сессии состоит из обмена тремя сообщениями, как показано ниже.

      LAC         LNS
      ---         ---
               <- OCRQ
      OCRP ->

      (Выполнена обработка вызова)

      OCCN ->
               <- ZLB ACK

Сообщение ZLB ACK передается в тех случаях, когда в очереди для данного партнера нет других сообщений.

5.3 Пересылка кадров PPP

По завершении организации туннеля из кадров PPP от удаленной системы, принимаемых LAC, вырезается CRC, байты канального кадрирования и «прозрачности», после чего выполняется инкапсуляция в L2TP и пересылка через подходящий туннель. LNS получает пакеты L2TP и обрабатывает инкапсулированные кадры PPP, как будто они были получены от локального интерфейса PPP.

Отправитель сообщения, связанного с конкретной сессией и туннелем, помещает идентификаторы Session ID и Tunnel ID (задается его партнером) в одноименные поля заголовков всех исходящих сообщений. С помощью этих полей кадры PPP мультиплексируются и демультиплексируются через один туннель между парой устройств LNS и LAC. Между кнонкретной парой устройств LNS и LAC может существовать множество туннелей, в каждом из которых быть организовано множество сессий.

Нулевые значения идентификаторов сессии и туннеля имеют специальное значение и недопустимо применять их в качестве Assigned Session ID или Assigned Tunnel ID. Для случаев когда значение Session ID еще не присвоено партнером (т. е., в процессе организации новой сессии или туннеля), в поле Session ID должно помещаться значение 0, а в сообщении должна использоваться Assigned Session ID AVP для идентификации сессии. Аналогично, для случаев когда значение Tunnel ID еще не было присвоено партнером, в поле Tunnel ID должно помещаться значение 0 с использованием для идентификации туннеля Assigned Tunnel ID AVP.

5.4 Использование порядковых номеров в канале данных

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

В отличии от канала управления L2TP, канал данных не использует порядковые номера для повтора передачи утерянных сообщений с данными. Порядковые номера в сообщениях с данными могут использоваться для обнаружения потери пактов и/или восстановления порядка, нарушенного при транспортировке. LAC может запросить включение порядковых номеров в сообщения сданными с помощью Sequencing Required AVP (см. параграф 4.4.6). Если данная AVP присутствует при организации сессии, порядковые номера должны включаться во все кадры. При отсутствии данной AVP использование порядковых номеров определяет LNS. Устройство LNS может включить или отключить использование порядковых номеров в сообщениях в любой момент, просто добавляя или исключая эти номера для передаваемых им пакетов. Таким образом, если устройство LAC получает сообщение с данными, включающее порядковый номер, оно должно начать использование порядковых номеров в передаваемых после этого сообщениях с данными. Если LNS возобновляет использование порядковых номеров после отказа, нумерация продолжается с того значения, на котором она была прервана ранее.

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

5.5 Keepalive (Hello)

Механизм keepalive используется в L2TP для того, чтобы отличить отказы в туннеле от продолжительных интервалов бездействия. Для этого используются управляющие сообщения Hello (см. параграф 6.5), передаваемые по истечении заданного интервала с момента приема последнего сообщения (данные или управление) из туннеля. Как и для прочих управляющих сообщений, если сообщение Hello не было доставлено, считается, что туннель не работоспособен и выполняется его сброс. Механизм сброса на транспортном уровне вкупе с сообщениями Hello обеспечивает обнаружение отказов в туннеле между LNS и LAC с любой стороны туннеля.

5.6 Разрыв сессии

Разрыв сессии может быть инициирован LAC или LNS и реализуется путем отправки управляющего сообщения CDN. После завершения последней сессии может быть разорвано и управляющее соединение (обычно так и происходит). Ниже приведен пример обмена управляющими соединениями для этого случая:

      LAC или LNS  LAC или LNS

      CDN ->
      (Очистка)

                   <- ZLB ACK
                     (Очистка)

 

5.7 Разрыв управляющего соединения

Разрыв управляющего соединения может быть инициирован LAC или LNS и выполняется путем передачи одного управляющего сообщения StopCCN. Получатель сообщения StopCCN должен передать ZLB ACK для подтверждения приема и поддерживать состояние управляющего соединения для корректного восприятия повторов StopCCN в течение по крайней мере интервала полного цикла повтора передачи (на случай потери ZLB). Рекомендуемая продолжительность полного цикла повтора передачи составляет 31 сек. (см. параграф 5.8). Ниже приведен пример обмена управляющими сообщениями.

      LAC или LNS  LAC или LNS

      StopCCN ->
      (Очистка)

                   <- ZLB ACK
                      (Ожидание)
                      (Очистка)

Реализация пожет «погасить» туннель целиком вместе с организованными в нем сессиями, передав StopCCN. Таким образом, не требуется разрывать каждую сессию отдельно при полном разрыве туннеля.

5.8 Гарантированная доставка управляющих сообщений

L2TP обеспечивает гарантированный транспорт для всех управляющих сообщений. Поля Nr и Ns в заголовке управляющего сообщения (см. параграф 3.1) относятся к этому транспорту. Функции верхнего уровня L2TP не связаны с повтором передачи и соблюдением порядка доставки управляющих сообщений. Использование скользящего окна порядковых номеров обеспечивает контроль перегрузок и повтор передачи управляющих сообщений. Каждый из партнеров поддерживает свое состояние для порядковых номеров передаваемых через туннель сообщений.

Порядковые номера передаваемых сообщений Ns начинаются с 0. В каждом следующем передаваемом сообщении порядковый номер увеличивается на 1. Модуль счетчика порядковых номеров составляет 65536. Порядковый номер в заголовке принятого сообщения рассматривается, как не превышающий последний принятый номер, если его значение попадает в диапазон, включающий 32767 предшествующих номеров и последний принятый номер. Например, если последний принятый номер равен 15, сообщения с номерами от 0 до 15 и от 32784 до 65535 будут рассматриваться, как сообщения с номерами меньше последнего. Такие сообщения трактуются, как дубликаты ранее принятых сообщений и при обработке игнорируются. Однако для обеспечения корректного подтверждения всех сообщений (на случай потери ZLB ACK) полученные дубликаты должны подтверждаться с применением надежного транспорта. Для этого подтверждение может «прицепляться» к сообщению из очереди или передаваться в виде отдельного ZLB ACK.

Передача всех сообщений, кроме подтверждений ZLB, увеличивает порядковый на 1. После передачи сообщения ZLB порядковый номер Ns не увеличивается.

Номер последнего принятого сообщения Nr используется для подтверждения полученных партнером L2TP сообщений. Это поле указывает порядковый номер, который партнер ожидает получить в следующем сообщении (например, Ns из последнего сообщения не ZLB + 1 по модулю 65536). Хотя значение Nr из полученного сообщения ZLB применяется для исключения сообщений из локальной очереди на повторную передачу (см. ниже), значение Nr для следующего сообщения не обновляется значением Ns из принятого ZLB.

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

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

При передаче каждого последующего сообщения интервал должен экспоненциально возрастать. Таким образом, если первый повтор был сделан через 1 секунду, второй следует делать по истечении 2 секунд, третий — после 4 и т. д. Реализация может ограничивать максимальный интервал между повторами. Это ограничение должно быть не меньше 8 секунд. Если после нескольких (по умолчанию рекомендуется 5, но это значение следует делать настраиваемым) повторов отклик от партнера не был получен, туннель и все сессии в нем должны быть сброшены.

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

Для управления передачей сообщений используется механизм скользящего окна. Рассмотрим двух партнеров — A и B. Предположим, что A задает Receive Window Size AVP со значением N в сообщении SCCRQ или SCCRP. Это позволяет B передать до N управляющих сообщений, не получив подтверждения доставки. После передачи N сообщений требуется ждать подтверждения, которое позволит сдвинуть окно и передать новое управляющее сообщение. Реализация может поддерживать приемное окно размером 1 (передав Receive Window Size AVP со значением 1), но должна воспринимать от партнера окна размером до 4 (т. е., возможность отправить до 4 сообщений без ожидания подтверждений). Значение 0 для Receive Window Size AVP является неприемлемым.

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

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

В Приложении B приведены примеры передачи, подтверждения и повтора управляющих сообщений.

6.0 Спецификация протокола управляющего соединения

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

6.1 Запрос SCCRQ

Управляющее сообщение SCCRQ8 служит для инициализации туннеля между LNS и LAC. Сообщение передается устройством LAC или LNS для инициирования процесса организации туннеля.

В сообщении SCCRQ должны присутствовать перечисленные ниже AVP:

Message Type AVP;

Protocol Version;

Host Name;

Framing Capabilities;

Assigned Tunnel ID.

Перечисленные ниже AVP также могут присутствовать в сообщениях SCCRQ:

Bearer Capabilities;

Receive Window Size;

Challenge;

Tie Breaker;

Firmware Revision;

Vendor Name.

6.2 Отклик SCCRP

Управляющие сообщения SCCRP9 передаются в ответ на получение сообщения SCCRQ. Отклик SCCRP служит для индикации восприятия запроса SCCRQ и показывает, что организацию туннеля следует продолжать.

В сообщении SCCRP должны присутствовать перечисленные ниже AVP:

Message Type;

Protocol Version;

Framing Capabilities;

Host Name;

Assigned Tunnel ID.

Перечисленные ниже AVP также могут присутствовать в сообщениях SCCRP:

Bearer Capabilities;

Firmware Revision;

Vendor Name;

Receive Window Size;

Challenge;

Challenge Response.

6.3 Отклик SCCCN

Сообщения SCCCN10 передаются в ответ на SCCRP. Сообщение SCCCN показывает завершение процесса организации туннеля.

В сообщении SCCCN должна присутствовать Message Type AVP.

Кроме того, в SCCCN может включаться Challenge Response AVP.

6.4 Уведомление StopCCN

Уведомление о разрыве управляющего соединения (StopCCN11) представляет собой управляющее сообщение, передаваемое LAC или LNS для информирования своего партнера о предстоящем разрыве туннеля и необходимости закрытия управляющего соединения. Кроме управляющего соединения неявно (без передачи каких-либо явных уведомлений) завершаются все активные сессии через этот туннель. Причина отправки такого запроса указывается в Result Code AVP. На это сообщение нет явного отклика и используется только неявное подтверждение ACK, передаваемое через гарантированный транспорт управляющих сообщений.

В StopCCN должны присутствовать следующие AVP:

Message Type;

Assigned Tunnel ID;

Result Code.

6.5 Сообщение HELLO

Управляющие сообщения HELLO в протоколе L2TP могут передаваться любым из партнеров в соединении LAC-LNS и служат для сохранения жизнеспособности туннеля (keepalive).

Передача сообщений HELLO и ее правила определяются реализацией. Партнеру недопустимо ожидать получения HELLO в какой-либо момент или интервал. Как и все сообщения через управляющий канал, приветствия подтверждаются получателем с помощью сообщения ZLB ACK или путем добавки данных подтверждения в обычное сообщение.

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

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

Сообщения HELLO являются «глобальными» для туннеля. Поле Session ID в сообщении HELLO должно иметь значение 0.

В сообщении HELLO должна присутствовать Message Type AVP.

6.6 Запрос для входящего вызова (ICRQ)

Управляющее сообщение ICRQ12 передается LAC для LNS при обнаружении входящего вызова. Оно является первым из трех сообщений, используемых для организации сессии в туннеле L2TP.

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

В сообщении ICRQ должны присутствовать перечисленные ниже AVP:

Message Type;

Assigned Session ID;

Call Serial Number.

Перечисленные ниже AVP также могут присутствовать в сообщениях ICRQ:

Bearer Type;

Physical Channel ID;

Calling Number;

Called Number;

Sub-Address.

6.7 Ответ на входящий вызов (ICRP)

Управляющее сообщение ICRP13 передается LNS устройству LAC в ответ на принятое от того сообщение ICRQ. Это второе из трех сообщений, используемых для организации сессии в туннеле L2TP.

ICRP служит для индикации получения и обработки ICRQ, указывая устройству LAC, что следует ответить на вызов, если это не было сделано ранее. Сообщение также позволяет указать параметры, требуемые для сессии L2TP.

В сообщениях ICRP должны присутствовать AVP Message Type и Assigned Session ID.

6.8 Входящий вызов принят (ICCN)

Управляющее сообщение ICCN14 передаются LAC устройству LNS в ответ на получение ICRP. Это сообщение является последним из трех сообщений, используемых для организации сессии в туннеле L2TP.

ICCN служит для индикации восприятия ICRP и ответа на входящий вызов, а также говорит о том, что сессию L2TP следует перевести в состояние established (организована). Сообщение также включает дополнительную информацию для LNS о параметрах, использованных при ответе на вызов (они не всегда доступны в момент передачи ICRQ).

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

Message Type;

(Tx) Connect Speed;

Framing Type.

Перечисленные ниже AVP также могут присутствовать в сообщениях ICCN.

Initial Received LCP CONFREQ;

Last Sent LCP CONFREQ;

Last Received LCP CONFREQ;

Proxy Authen Type;

Proxy Authen Name;

Proxy Authen Challenge;

Proxy Authen ID;

Proxy Authen Response;

Private Group ID;

Rx Connect Speed;

Sequencing Required.

6.9 Запрос для исходящего вызова (OCRQ)

Управляющее сообщение OCRQ15 передаются от LNS устройству LAC для индикации исходящего вызова со стороны LAC. Это первое из трех сообщений при организации сессии в туннеле L2TP.

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

Устройство LNS должно иметь Bearer Capabilities AVP, принятую от LAC в процессе организации туннеля, для запроса исходящего вызова у этого устройства LAC.

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

Message Type;

Assigned Session ID;

Call Serial Number;

Minimum BPS;

Maximum BPS;

Bearer Type;

Framing Type;

Called Number.

Кроме того, в OCRQ может включаться Sub-Address AVP.

6.10 Отклик для исходящего вызова (OCRP)

Управляющее сообщение OCRP16 передается от LAC к устройству LNS в ответ на полученное сообщение OCRQ. Это второе из трех сообщений, используемых для организации сессии в туннеле L2TP.

OCRP показывает, что устройство LAC способно попытаться организовать исходящее соединение и возвратить некоторые параметры, относящиеся к такой попытке.

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

Message Type;

Assigned Session ID.

Кроме того, в OCRP может включаться Physical Channel ID AVP.

6.11 Исходящее соединение организовано (OCCN)

Управляющее сообщение OCCN17 передается LAC устройству LNS вслед за сообщением OCRP после организации исходящего соединения. Это сообщение является последним из трех сообщений, используемых для организации сессии в туннеле L2TP.

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

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

Message Type;

(Tx) Connect Speed;

Framing Type.

Перечисленные ниже AVP также могут присутствовать в сообщениях OCCN.

Rx Connect Speed;

Sequencing Required.

6.12 Уведомление о разрыве соединения (CDN)

Управляющее сообщение CDN18 передается устройством LAC или LNS для запроса разрыва указанного соединения в туннеле. Цель этого сообщения заключается в информировании партнера о разрыве соединения с указанием причины такого разрыва. Партнер должен освободить все связанные с соединением ресурсы, не передавая отправителю никакой индикации результата очистки.

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

Message Type;

Result Code;

Assigned Session ID.

Кроме того, в CDN может включаться Q.931 Cause Code AVP.

6.13 Уведомление об ошибке в сети WAN (WEN)

Управляющее сообщение WEN19 передается LAC устройству LNS для индикации ошибки в сети WAN (ошибка на интерфейсе, поддерживающем PPP). Счетчики для таких сообщений являются кумулятивными. Сообщения этого типа следует передавать лишь при возникновении ошибок, но не чаще 1 раза в течение 60 секунд. При организации нового соединения счетчики ошибок сбрасываются.

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

Message Type;

Call Errors.

6.14 Установка параметров канала (SLI)

Управляющее сообщение SLI20 передается LNS устройству LAC для установки опций, согласуемых PPP. Эти опции могут меняться в течение действия соединения и устройство LAC должно обеспечивать возможность изменения своей внутренней информации о соединении и поведения для активной сессии PPP.

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

Message Type;

ACCM.

7.0 Машина состояний управляющего соединения

Обмен управляющими сообщениями, описанными в разделе 6, осуществляется в соответствии с таблицами состояний, рассмотренными ниже. Таблицы приведены для входящих и исходящих вызовов, а также для организации самого туннеля. В таблицах состояний не приводятся тайм-ауты и повторы передач, которые определяются семантикой, рассмотренной в параграфе 5.8.

7.1 Операции протокола управляющего соединения

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

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

Неприемлемым считается управляющее сообщение, которое относится к обязательным типам (см. параграф 4.4.1), но этот тип не известен реализации, или получено с нарушением порядка (например, SCCCN в ответ на SCCRQ).

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

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

Недопустимо рассматривать сказанное выше, как разрешение на отправку некорректно сформированных AVP, это лишь рекомендации по обработке полученных сообщений с некорректным форматом. Невозможно перечислить все возможные ошибки формата того или иного сообщения и дать рекомендации на каждый случай. Тем не менее, рассмотрим один из примеров искаженной, но исправимой AVP, когда Rx Connect Speed AVP (атрибут 38) принимается со значением поля размера 8 вместо 10, а BPS указана в двух октетах вместо четырех. Поскольку Rx Connect Speed AVP не является обязательной, описанную ситуацию не следует считать критической. В этом случае управляющее сообщение следует воспринять, как будто данная AVP отсутствует (тем не менее, протоколируя этот факт).

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

Этапы организации туннеля рассмотрены в Приложении B.1.

7.2 Состояния управляющего соединения

Протокол управляющих соединений L2TP не различается для LNS и LAC, но различается для инициатора и получателя. Инициатором считается тот партнер, который начал организацию туннеля (при возникновении конфликта — победитель). Поскольку LAC и LNS могут быть инициаторами, возможно возникновение конфликтов. Для разрешения конфликтов используется Tie Breaker AVP, описанная в параграфе 4.4.3.

7.2.1 Организация управляющего соединения

Состояние

Событие

Действие

Новое состояние

idle

Локальный запрос Open

Передача SCCRQ

wait-ctl-reply

idle

Получение приемлемого SCCRQ

Передача SCCRP

wait-ctl-conn

idle

Получение неприемлемого SCCRQ

Очистка

idle

idle

Получение SCCRP

Передача StopCCN, очистка

idle

idle

Получение SCCCN

Очистка

idle

wait-ctl-reply

Получение приемлемого SCCRP

Передача SCCCN и события tunnel-open для ожидания сессий

established

wait-ctl-reply

Получение неприемлемого SCCRP

Передача StopCCN, очистка

idle

wait-ctl-reply

Получение SCCRQ, потеря tie-breaker

Очистка, переустановка SCCRQ в очередь для состояния idle

idle

wait-ctl-reply

Получение SCCCN

Передача StopCCN, очистка

idle

wait-ctl-conn

Получение приемлемого SCCCN

Передача события tunnel-open для ожидания сессий

established

wait-ctl-conn

Получение неприемлемого SCCCN

Передача StopCCN, очистка

idle

wait-ctl-conn

Получение SCCRP, SCCRQ

Передача StopCCN, очистка

idle

established

Локальный запрос Open (новый вызов)

Передача события tunnel-open для ожидания сессий

established

established

Административное закрытие туннеля

Передача StopCCN, очистка

idle

established

Получение SCCRQ, SCCRP, SCCCN

Передача StopCCN, очистка

idle

Idle,
wait-ctl-reply,
wait-ctl-conn,
established

Получение StopCCN

Очистка

idle

Состояния, связанные с LNS и LAC при организации управляющего соединения перечислены ниже.

idle

Как инициатор, так и получатель начинают с этого состояния. Инициатор передает сообщение SCCRQ из этого состояния, а получатель сохраняет такое состояние до получения SCCRQ.

wait-ctl-reply

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

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

wait-ctl-conn

Состояние ожидания SCCCN. При получении отклик проверяется. Туннель организуется или разрывается, если произошел отказ при проверке полномочий.

established

Организованное соединение может быть разорвано по местным условиям или в ответ на получение Stop-Control-Connection-Notification. При разрыве соединения по местным условиям инициатор должен передать Stop-Control-Connection-Notification и очистить туннель.

Если инициатор получает Stop-Control-Connection-Notification, он также должен очистить туннель.

7.3 Синхронизация

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

7.4 Входящие вызовы

Сообщение Incoming-Call-Request генерируется LAC при обнаружении входящего вызова (например, звонок по телефонной линии). LAC выбирает Session ID и порядковый номер, а также указывает тип подателя вызова. Для модемов всегда следует указывать аналоговый тип. Для вызовов ISDN следует указывать цифровой тип, если используется неограниченное цифровое обслуживание или адаптация скорости, и аналоговый тип при вовлечении модемов. Параметры Calling Number, Called Number и Subaddress могут включаться в сообщение, если они доступны из телефонной сети.

После того, как устройство LAC передаст Incoming-Call-Request, оно ждет отклика от LNS, но это не обязательно будет вызов из телефонной сети. LNS может отвергнуть вызов по причине:

  • отсутствия ресурсов для обслуживания дополнительной сессии;

  • поля dialed, dialing или subaddress не соответствуют имеющему полномочия пользователю;

  • тип вызова не поддерживается или для него нет разрешения.

Если устройство LNS воспринимает вызов, оно возвращает сообщение Incoming-Call-Reply. Получив такое сообщение, LAC пытается организовать соединение. Финальное при организации соединения сообщение от LAC к LNS показывает, что на обеих сторонах следует установить для вызова состояние established (соединение организовано). Если вызов был прерван до того, как устройство LNS восприняло его, LAC будет предавать сообщение Call-Disconnect-Notify для индикации этого.

Когда телефонный клиент «кладет трубку» соединение разрывается обычным способом и LAC передает сообщение Call-Disconnect-Notify. Если устройство LNS хочет сбросить (очистить) соединение, оно передает сообщение Call-Disconnect-Notify и сбрасывает свою сессию.

7.4.1 Состояния LAC для входящих вызовов

Состояние

Событие

Действие

Новое состояние

idle

Звонок или Ready с индикацией входящего вызова

Инициирование локального создания туннеля

wait-tunnel

idle

Получение ICCN, ICRP, CDN

Очистка

idle

wait-tunnel

Отключение со стороны вызывающего или локальный запрос на закрытие

Очистка

idle

wait-tunnel

Создание туннеля

Передача ICRQ

wait-reply

wait-reply

Получение приемлемого ICRP

Передача ICCN

established

wait-reply

Получение неприемлемого ICRP

Передача CDN, очистка

idle

wait-reply

Получение ICRQ

Передача CDN, очистка

idle

wait-reply

Получение CDN, ICCN

Очистка

idle

wait-reply

Отключение со стороны вызывающего или локальный запрос на закрытие

Передача CDN, очистка

idle

established

Получение CDN

Очистка

idle

established

Получение ICRQ, ICRP, ICCN

Передача CDN, очистка

idle

established

Отключение со стороны вызывающего или локальный запрос на закрытие

Передача CDN, очистка

idle

Состояния LAC для входящих вызовов перечислены ниже.

idle

Устройство LAC обнаружило входящий вызов на одном из своих интерфейсов. Обычно это звонок по аналоговой линии или входящее сообщение Q.931 SETUP, полученное ISDN TE. LAC инициирует свою машину организации туннеля и переходит в состояние ожидания подтверждения существования туннеля.

wait-tunnel

В этом состоянии сессия ожидает открытия управляющего соединения или проверки факта существования туннеля. После того, как туннель создан/обнаружен может быть выполнен обмен управляющими сессией сообщениями, первым из которых является Incoming-Call-Request.

wait-reply

Устройство LAC получило сообщение CDN, показывающее, что LNS не желает принимать вызов (общая ошибка или отказ в восприятии), и возвращается в состояние idle или получило сообщение Incoming-Call-Reply, показывающее, что вызов воспринят, после чего LAC передает сообщение Incoming-Call-Connected и переходит в состояние established.

established

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

  • событие на связанном с соединением интерфейсе — LAC передает сообщение Call-Disconnect-Notify;

  • прием сообщения Call-Disconnect-Notify — LAC очищает состояние и разрывает соединение;

  • локальная причина — LAC передает сообщение Call-Disconnect-Notify.

7.4.2 Состояния LNS для входящих вызовов

Состояние

Событие

Действие

Новое состояние

idle

Получение приемлемого ICRQ

Передача ICRP

wait-connect

idle

Получение неприемлемого ICRQ

Передача CDN, очистка

idle

idle

Получение ICRP

Передача CDN, очистка

idle

idle

Получение ICCN

Очистка

idle

wait-connect

Получение приемлемого ICCN

Подготовка для данных

established

wait-connect

Получение неприемлемого ICCN

Передача CDN, очистка

idle

wait-connect

Получение ICRQ, ICRP

Передача CDN, очистка

idle

idle,
wait-connect,
established

Получение CDN

Очистка

idle

wait-connect,
established

Локальный запрос закрытия

Передача CDN, очистка

idle

established

Получение ICRQ, ICRP, ICCN

Передача CDN, очистка

idle

Состояния LNS для входящих вызовов перечислены ниже.

idle

Принято сообщение Incoming-Call-Request. Если запрос не воспринимается, в ответ передается сообщение Call-Disconnect-Notify и устройство LNS сохраняет состояние idle. Если сообщение Incoming-Call-Request воспринято, в ответ передается Incoming-Call-Reply и сессия переводится в состояние wait-connect.

wait-connect

Если соединение на устройстве LAC продолжает существовать, LAC передает сообщение Incoming-Call-Connected устройству LNS, которое после этого переходит в состояние established. LAC может передать сообщение Call-Disconnect-Notify для индикации того, что для исходящего вызова соединение не организовано. Это может происходить, например, в тех случаях, когда инициатор звонка случайно соединился с LAC вместо номера для голосовой связи и модем не смог согласовать соединение.

established

Сессия может быть прервана по приему сообщения Call-Disconnect-Notify от LAC или передачей тому сообщения Call-Disconnect-Notify. Далее происходит сброс соединения на обеих сторонах независимо от того, кто был инициатором разрыва.

7.5 Исходящие вызовы

Исходящие соединения инициируются устройством LNS, которое инструктирует LAC по организации вызова. С исходящими вызовами используются три соединения: Outgoing-Call-Request, Outgoing-Call-Reply и Outgoing-Call-Connected. LNS передает сообщение Outgoing-Call-Request, указывающее телефонный номер вызываемого, субадрес и другие параметры. Устройство LAC должно ответить на Outgoing-Call-Request сообщением Outgoing-Call-Reply после того, как определит наличие требуемых для вызова компонент и административного разрешения на вызов (например, разрешение данному LNS использовать международные звонки). После организации исходящего соединения LAC передает LNS сообщение Outgoing-Call-Connected с результатом организации соединения.

7.5.1 Состояния LAC для исходящих вызовов

Состояние

Событие

Действие

Новое состояние

idle

Получение приемлемого ICRQ

Передача OCRP, звонок

wait-cs-answer

idle

Получение неприемлемого ICRQ

Передача CDN, очистка

idle

idle

Получение OCRP

Передача CDN, очистка

idle

idle

Получение OCCN, CDN

Очистка

idle

wait-cs-answer

Ответ, обнаружено кадрирование

Передача OCCN

established

wait-cs-answer

Отказ

Передача CDN, очистка

idle

wait-cs-answer

Получение OCRQ, OCRP, OCCN

Передача CDN, очистка

idle

established

Получение OCRQ, OCRP, OCCN

Передача CDN, очистка

idle

wait-cs-answer, established

Получение CDN

Очистка

idle

established

Разрыв соединения, локальный запрос закрытия

Передача CDN, очистка

idle

Состояния LAC для исходящих вызовов перечислены ниже.

idle

Если сообщение Outgoing-Call-Request принято с ошибкой, следует ответить сообщением Call-Disconnect-Notify. В остальных случаях выделяется физический канал и передается сообщение Outgoing-Call-Reply. Организуется исходящее соединение и выполняется переход в состояние wait-cs-answer.

wait-cs-answer

Если вызов не был завершен или закончился отсчет таймера ожидания завершения соединения, передается сообщение Call-Disconnect-Notify с подходящим кодом ошибки и происходит переход в состояние idle. Если коммутируемое соединение организовано и обнаружено кадрирование, передается сообщение Outgoing-Call-Connected, показывающее успех, и выполняется переход в состояние established.

established

Если устройство LAC получает сообщение Call-Disconnect-Notify, телефонное соединение должно быть разорвано с использованием подходящего механизма, а сессия tсброшена (очищена). Если соединение было разорвано клиентом или вызываемым интерфейсом, устройству LNS должно быть передано сообщение Call-Disconnect-Notify. Отправитель Call-Disconnect-Notify возвращается в состояние idle после завершения отправки сообщения.

7.5.2 Состояния LNS для исходящих вызовов

Состояние

Событие

Действие

Новое состояние

idle

Локальный запрос

Инициирование локального tunnel-open

wait-tunnel

idle

Получение OCCN, OCRP, CDN

Очистка

idle

wait-tunnel

tunnel-open

Передача OCRQ

wait-reply

wait-reply

Получение приемлемого OCRP

нет

wait-connect

wait-reply

Получение неприемлемого OCRP

Передача CDN, очистка

idle

wait-reply

Получение OCCN, OCRQ

Передача CDN, очистка

idle

wait-connect

Получение OCCN

нет

established

wait-connect

Получение OCRQ, OCRP

Передача CDN, очистка

idle

idle,
wait-reply,
wait-connect,
established

Получение CDN

Очистка

idle

established

Получение OCRQ, OCRP, OCCN

Передача CDN, очистка

idle

wait-reply,
wait-connect,
established

Локальный запрос на разрыв

Передача CDN, очистка

idle

wait-tunnel

Локальный запрос на разрыв

Очистка

idle

Состояния LNS для исходящих вызовов перечислены ниже.

idle, wait-tunnel

При инициировании исходящего соединения сначала организуется туннель, как в состояниях idle и wait-tunnel для входящего вызова на LAC. После организации туннеля устройству LAC передается сообщение Outgoing-Call-Request и сессия переходит в состояние wait-reply.

wait-reply

При получении сообщения Call-Disconnect-Notify это рассматривается, как ошибка, сессия очищается и возвращается в состояние idle. При получении Outgoing-Call-Reply вызов обрабатывается и сессия переходит в состояние wait-connect.

wait-connect

При получении сообщения Call-Disconnect-Notify это рассматривается, как ошибка, сессия очищается и возвращается в состояние idle. При получении Outgoing-Call-Connected организация соединения завершается и через него может начинаться передача данных.

established

При получении сообщения Call-Disconnect-Notify соединение разрывается по причине, указанной в Result и Cause Code; сессия переходит в состояние idle. Если устройство LNS решает прервать сессию, оно передает Call-Disconnect-Notify устройству LAC, после чего очищает сессию и переводит ее в состояние idle.

7.6 Разрыв туннеля

Разрыв туннеля может быть инициирован любым из партнеров путем передачи сообщения Stop-Control-Connection-Notification. Отправителю этого уведомления следует дождаться (ограниченное время) получения подтверждения доставки данного сообщения прежде, чем сбрасывать связанные с туннелем данные управления. Получателю такого уведомления следует отправить подтверждение приема отправителю и после этого сбросить связанные с туннелем данные управления.

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

8.0 L2TP в разных средах

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

8.1 L2TP через UDP/IP

L2TP использует зарегистрированный порт UDP 1701 [RFC1700]. Весь пакет L2TP, включая данные и заголовок L2TP, передается в виде дейтаграммы UDP. Инициатор туннеля L2TP выбирает доступный выходной порт UDP (не обязательно 1701) и передает пакет в порт 1701 по желаемому адресу. Получатель этого пакета выделяет доступный порт в своей системе (не обязательно 1701) и передает через него отклик, используя номер порта UDP и адрес инициатора, указывая в качестве порта отправителя выбранный в своей системе свободный порт. После выбора портов для отправки и получения пакетов, номера этих портов должны сохраняться в течение срока использования туннеля.

Высказывалось предположение, что выбор получателем произвольного порта-источника (вместо использованного для приема порта 1701) может осложнить прохождение пакетов L2TP через некоторые устройства NAT. Разработчикам следует принимать во внимание этот аспект при выборе порта для отправки отклика.

При прохождении пакетов L2TP через инфраструктуру IP возможна их фрагментация. В L2TP не используется специальных мер оптимизации для таких случаев. Реализация LAC может заставить свой LCP согласовать конкретное значение MRU, оптимизированное для среды LAC, в которой MTU на пути прохождения пакетов L2TP можно предположить согласованным.

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

Порт 1701 применяется как для пакетов L2F [RFC2341], так и для пакетов L2TP. Поле Version в заголовке может применяться для того, чтобы различать эти два типа пакетов (L2F использует значение 1, а L2TP, описанный в данном документе, — 2). Реализации L2TP в системах, не поддерживающих L2F, должны отбрасывать пакеты L2F без уведомления.

Для клиентов PPP, использующих L2TP через туннель UDP/IP, канальные характеристики PPP могут приводить к смене порядка и отбрасыванию пакетов без уведомления. Изменение порядка может нарушать работу не относящхся к IP протоколов, передаваемых через PPP, особенно протоколов ЛВС (например, протоколов мостов). Отбрасывание пакетов может нарушать работу протоколов, которые используют попакетную индикацию ошибок (например, протоколы сжатия заголовков TCP). Сохранение порядка можно обеспечить с помощью порядковых номеров в пакетах данных L2TP, если передаваемые через PPP чувствительны к нарушению порядка доставки. Требования отдельных протоколов к упорядоченной доставке выходят за рамки данного документа.

Вопрос с отбрасыванием пакетов без уведомления более сложен для некоторых протоколов. Если включена гарантированная доставка PPP [RFC1663], протокол не будет сталкиваться с потерей пакетов. При использовании порядковых номеров L2TP сам протокол L2TP сможет обнаруживать потерю пакетов. Для случая LNS в устройстве присутствуют стеки протоколов PPP и L2TP, поэтому сигнализация о потере пакетов может быть очень точной, как при получении пакетов с ошибками CRC. Если LAC и стек PPP используются совместно, этот метод также можно применить. Если же LAC и клиент PPP физически разделены, похожую сигнализацию можно обеспечить путем передачи клиенту PPP пакетов с ошибкой CRC. Отметим, что это будет сильно осложнять решение клиентских проблем с линией, поскольку статистика клиента не сможет различить ошибки в среде от имитированных устройством LAC ошибок. Кроме того, использование этого метода возможно не на всем оборудовании.

При использовании компрессии VJ и отсутствии гарантированной доставки PPP и порядковых номеров каждая потеря пакета будет приводить к вероятности пересылки сегмента TCP с некорректным содержимым 2-16 [RFC1144]. В тех случаях, когда комбинация частоты потери пакетов с указанной вероятностью некорректной пересылки не приемлема, сжатие заголовков TCP не следует использовать.

В общем случае следует помнить, что транспорт L2TP/UDP/IP не является надежным. Как и для любой среды PPP с возможными потерями следует принимать соответствующие меры для протоколов, чувствительных к потерям. К таким протоколам относятся протоколы сжатия заголовков и шифрования, которые в своей работе опираются на предыдущие пакеты.

8.2 IP

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

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

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

9.1 Безопасность конечных точек туннеля

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

Для выполнения аутентификации устройства LAC и LNS должны использовать общий секрет. Каждая из сторон туннеля использует один и тот же секрет, выступая как в качестве аутентифицируемой, так и в качестве аутентифицирующей стороны. По причине использования одного секрета AVP для аутентификации туннеля включают дифференцирующие значения в полях CHAP ID для каждого расчета цифровой подписи сообщения (с целью предотвращения повторного использования перехваченных пакетов).

Значения Assigned Tunnel ID и Assigned Session ID (см. параграф 4.4.3) следует выбирать непредсказуемым способом, а не перебирать последовательно или по иному алгоритму. Это поможет предотвратить захват сессии злоумышленниками, не имеющими доступа к пакетам между устройствами LAC и LNS.

9.2 Защита на уровне пакетов

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

9.3 Сквозная защита

Защита потока пакетов L2TP на уровне транспорта обеспечивает и защиту данных в туннелируемых пакетах PPP при их транспортировке от LAC к LNS. Такую защиту не следует рассматривать, как замену сквозной защиты между взаимодействующими хостами или приложениями.

9.4 L2TP и IPsec

При работе с IP протокол IPsec обеспечивает защиту на уровне пакетов с использованием ESP и/или AH. Все пакеты управления и данных L2TP для конкретного туннеля воспринимаются системой IPsec, как однотипные пакеты данных UDP/IP.

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

IPsec также поддерживает функции контроля доступа, которые являются обязательными для реализаций IPsec. Эти функции позволяют фильтровать пакеты по параметрам сетевого и транспортного уровня (таким, как адреса IP, номера портов и т. п.). В модели туннелирования L2TP аналогичные функции выполняются на уровне PPP или сетевом уровне над L2TP. Эти функции контроля доступа на сетевом уровне могут реализоваться на LNS с помощью фирменных функций проверки полномочий на базе аутентификации пользователей PPP или непосредственно на сетевом уровне при сквозном использовании транспортного режима IPsec между взаимодействующими хостами. Требования к механизмам контроля доступа не являются частью спецификации L2TP и выходят за рамки этого документа.

9.5 Аутентификация PPP

L2TP определяет AVP, которые могут передаваться в процессе организации сеанса для обеспечения пересылки управляющей информации PPP, имеющейся на LAC устройству LNS для ее проверки (см. параграф 4.4.5). Это предполагает доверительные отношения на устройстве LAC от имени LNS. Если устройство LNS использует proxy-аутентификацию, оно должно обеспечивать возможность ее отключения для выполнения нового раунда аутентификации PPP по инициативе LNS (может включать новый раунд согласования LCP).

10.0 Согласование с IANA

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

10.1 Атрибуты AVP

Как указано в параграфе 4.1, AVP включают поля Vendor ID, Attribute и Value. Для Vendor ID = 0 IANA будет поддерживать реестр выделенных значений Attribute, а в некоторых случаях и сами значения. Распределение атрибутов 0 — 39 описано в параграфе 4.4. Остальные значения доступны для распределения через процедуру IETF Consensus [RFC 2434].

10.2 Значения Message Type AVP

Как указано в параграфе 4.4.1, Message Type AVP (Attribute Type 0) имеет значение, распределяемое IANA. Значения 0 — 16 описаны в параграфе 3.2, остальные значения доступны для распределения по процедуре IETF Consensus [RFC 2434]

10.3 Значения Result Code AVP

Как указано в параграфе 4.4.2, Result Code AVP (Attribute Type 1) содержит три поля. Два из этих полей (Result Code и Error Code) используют значения, распределяемые IANA.

10.3.1 Значения поля Result Code

Result Code AVP может включаться в сообщения CDN и StopCCN. Допустимые значения поля Result Code данной AVP зависят от Message Type AVP. Для сообщений StopCCN значения 0 — 7 определены в параграфе 4.4.2; для сообщений StopCCN в том же параграфе определены значения 0 — 11. Остальные значения поля Result Code для обоих типов сообщений доступны для распределения по процедуре IETF Consensus [RFC 2434].

10.3.2 Значения поля Error Code

Значения 0 — 7 определены в параграфе 4.4.2. Значения 8 — 32767 доступны для распределения по процедуре IETF Consensus [RFC 2434]. Оставшиеся значения поля Error Code доступны для распределения по процедуре First Come First Served [RFC 2434].

10.4 Framing Capabilities и Bearer Capabilities

Framing Capabilities AVP и Bearer Capabilities AVP (см. параграф 4.4.3) содержат 32-битовые маски. Использование битов этих масок определяется по процедуре Standards Action [RFC 2434].

10.5 Значения Proxy Authen Type AVP

Proxy Authen Type AVP (Attribute Type 29) использует значения, распределяемые IANA. Значения 0 — 5 определены в параграфе 4.4.5, оставшиеся значения доступны для распределения по процедуре First Come First Served [RFC 2434].

10.6 Биты заголовка AVP

В заголовке AVP имеется четыре резервных поля. Использование этих полей возможно только в соответствии с процедурой Standards Action [RFC 2434].

11.0 Литература

[DSS1] ITU-T Recommendation, «Digital subscriber Signaling System No. 1 (DSS 1) — ISDN user-network interface layer 3 specification for basic call control», Rec. Q.931(I.451), May 1998

[KPS] Kaufman, C., Perlman, R., and Speciner, M., «Network Security: Private Communications in a Public World», Prentice Hall, March 1995, ISBN 0-13-061466-1

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1034] Mockapetris, P., «Domain Names — Concepts and Facilities», STD 13, RFC 1034, November 1987.

[RFC1144] Jacobson, V., «Compressing TCP/IP Headers for Low-Speed Serial Links», RFC 1144, February 1990.

[RFC1661] Simpson, W., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, July 1994.

[RFC1662] Simpson, W., «PPP in HDLC-like Framing», STD 51, RFC 1662, July 1994.

[RFC1663] Rand, D., «PPP Reliable Transmission», RFC 1663, July 1994.

[RFC1700] Reynolds, J. and J. Postel, «Assigned Numbers», STD 2, RFC 170021, October 1994. См. также: http://www.iana.org/numbers.html

[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, «The PPP Multilink Protocol (MP)», RFC 1990, August 1996.

[RFC1994] Simpson, W., «PPP Challenge Handshake Authentication Protocol (CHAP)», RFC 1994, August 1996.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, «Remote Authentication Dial In User Service (RADIUS)», RFC 213822, April 1997.

[RFC2277] Alvestrand, H., «IETF Policy on Character Sets and Languages», BCP 18, RFC 2277, January 1998.

[RFC2341] Valencia, A., Littlewood, M. and T. Kolar, «Cisco Layer Two Forwarding (Protocol) L2F», RFC 2341, May 1998.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240123, November 1998.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, «Point-to-Point Tunneling Protocol (PPTP)», RFC 2637, July 1999.

[STEVENS] Stevens, W. Richard, «TCP/IP Illustrated, Volume I The Protocols», Addison-Wesley Publishing Company, Inc., March 1996, ISBN 0-201-63346-9

12.0 Благодарности

Базовые концепции и многие из протокольных конструкций L2TP заимствованы из L2F [RFC2341] и PPTP [PPTP], авторами которых являются A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn.

Dory Leifer внес важные уточнения в определения для протокола L2TP и существенный вклад в редактирование документа.

Steve Cobb и Evan Caves переработали таблицы машины состояний.

Barney Wolff внес много предложений по механизму аутентификации конечных точек.

John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer и Rich Shea внесли существенные предложения и сделали обзор на 43-й конференции IETF в Orlando, FL., что существенно повысило уровень ясности данного документа и сделало его более читаемым.

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

Gurdeep Singh Pall

Microsoft Corporation

Redmond, WA

EMail: gurdeep@microsoft.com

Bill Palter

RedBack Networks, Inc

1389 Moffett Park Drive

Sunnyvale, CA 94089

EMail: palter@zev.net

Allan Rubens

Ascend Communications

1701 Harbor Bay Parkway

Alameda, CA 94502

EMail: acr@del.com

W. Mark Townsley

cisco Systems

7025 Kit Creek Road

PO Box 14987

Research Triangle Park, NC 27709

EMail: townsley@cisco.com

Andrew J. Valencia

cisco Systems

170 West Tasman Drive

San Jose CA 95134-1706

EMail: vandys@cisco.com

Glen Zorn

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

EMail: gwz@acm.org

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

Николай Малых

nmalykh@gmail.com

Приложение A. Slow Start и Congestion Avoidance на канале управления

Хотя каждая из сторон указывает максимальный размер приемного окна, рекомендуется использовать для передачи пакетов управления механизмы замедленного старта и предотвращения перегрузок. Описанные здесь методы основаны на алгоритме предотвращения перегрузок TCP, описанном в параграфе 21.6 книги W. Richard Stevens TCP/IP Illustrated, Volume I [STEVENS].

Упомянутые механизмы используют несколько переменных. Размер окна насыщения (CWND) определяет число пакетов, которые отправитель может предать до получения подтверждения. Значение CWND может изменяться, как описано ниже. Однако следует отметить, что CWND ни в коем случае не может превосходить размер анонсируемый окна, полученный из Receive Window AVP (в последующем тексте предполагается, что увеличение ограничено значением Receive Window Size). Переменная SSTHRESH24 определяет переключение из режима замедленного старта в режим предотвращения перегрузки. Механизм замедленного старта используется до тех пор, пока CWND < SSTHRESH.

Отправитель начинает с фазы замедленного старта. Для CWND устанавливается начальное значение в 1 пакет, а для SSTHRESH — размер анонсированного окна (берется из Receive Window AVP). После этого отправитель передает один пакет и ждет подтверждения его доставки (явного или прицепленного к данным). При получении подтверждения размер окна насыщения увеличивается с 1 до 2. В процессе замедленного старта значение CWND увеличивается на 1 при получении каждого ACK (явно в ZLB или с данными). Увеличение CWND на 1 при каждом ACK ведет к удвоению CWND за каждый период кругового обхода, что ведет к экспоненциальному росту размера окна. Когда значение CWND достигает SSTHRESH, фаза замедленного старта завершается и начинается фаза предотвращения перегрузок.

В фазе предотвращения перегрузок рост CWND замедляется. Более конкретно, размер окна увеличивается на 1/CWND при получении каждого нового ACK. Т. е., значение CWND увеличивается не 1 после приема CWND новых пакетов ACK. Увеличение размера окна в фазе предотвращения перегрузок эффективно является линейным — CWND увеличивается на 1 за каждый период кругового обхода.

При возникновении перегрузки (указывается включением повтора передачи) для SSTHRESH устанавливается значение ½ CWND, а для окна насыщения (CWND) устанавливается значение 1. После этого отправитель возвращается в фазу замедленного старта.

Приложение B. Примеры управляющих сообщений

B.1. Этапы организации туннеля

В этом примере LAC организует туннель, при организации которого обе стороны поочередно передают сообщения. Этот пример показывает финальное подтверждение, явно передаваемое в сообщении ZLB ACK. Другим вариантом может служить добавление подтверждения в сообщение, передаваемое в ответ на ICRQ или OCRQ, которое явно передаст сторона-инициатор.

          LAC или LNS              LNS или LAC
          -----------              -----------
          SCCRQ     ->
          Nr: 0, Ns: 0
                                   <-     SCCRP
                                   Nr: 1, Ns: 0
          SCCCN     ->
          Nr: 1, Ns: 1
                                   <-       ZLB
                                   Nr: 2, Ns: 1

 

B.2. Потеря пакета с повторной передачей

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

            LAC                               LNS
            ---                               ---
        ICRQ      ->
        Nr: 1, Ns: 2

                         (потеря пакета) <-      ICRP
                                         Nr: 3, Ns: 1

      (пауза; таймер LAC запускается первым и первым завершает отсчет)

       ICRQ      ->
       Nr: 1, Ns: 2

       (Понимая, что этот пакет уже был передан, LNS отбрасывает его и передает ZLB)
                                         <-       ZLB
                                         Nr: 3, Ns: 2

                       (завершается отсчет таймера повтора передачи в LNS)

                                         <-      ICRP
                                         Nr: 3, Ns: 1
       ICCN      ->
       Nr: 2, Ns: 3

                                         <-       ZLB
                                         Nr: 4, Ns: 2

 

Приложение C. Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF’s procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.»

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

Полное заявление авторских прав

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Layer Two Tunneling Protocol.

2Network Access Server — сервер доступа в сеть.

3Digital Subscriber Line.

4Authentication, Authorization and Accounting — аутентификация, проверка полномочий и учет.

5Attribute-Value Pair — пара «атрибут-значение».

6Mandatory — обязательный.

7Hidden — скрытый.

8Start-Control-Connection-Request — запрос на организацию управляющего соединения.

9Start-Control-Connection-Reply — отклик на запрос организации управляющего соединения.

10Start-Control-Connection-Connected — управляющее соединение организовано.

11Stop-Control-Connection-Notification.

12Incoming-Call-Request.

13Incoming-Call-Reply.

14Incoming-Call-Connected.

15Outgoing-Call-Request.

16Outgoing-Call-Reply

17Outgoing-Call-Connected.

18Call-Disconnect-Notify.

19WAN-Error-Notify.

20Set-Link-Info.

21В соответствии с RFC 3232 этот документ утратил силу. Данные доступны по ссылке. Прим. перев.

22Документ признан устаревшим и заменен RFC 2865. Прим. перев.

23Документ признан устаревшим и заменен RFC 4301. Прим. перев.

24В оригинале ошибочно указано SSHTRESH. См. https://www.rfc-editor.org/errata_search.php?eid=401. Прим. перев.