Интегрированные сети ISDN
PPP-туннелирование
Рисунок 18. PPP-туннелирование
5.1. Установление контрольного соединения
Управляющее соединение является первичным, которое должно быть реализовано между LAC и LNS, прежде чем запускать сессию. Установление управляющего соединения включает в себя безопасную идентификацию партнера, а также определение версии L2TP, возможностей канала, кадрового обмена и т.д.. Для установления управляющего соединения осуществляется обмен тремя сообщениями. Типичным является ниже приведенный обмен:
LAC или LNS LAC или LNS
SCCRQ ->
SCCCN ->
Если в очереди нет больше сообщений для партнера, посылается ZLB ACK.
5.1.1. Аутентификация туннеля
L2TP включает в себя простую, опционную, CHAP-подобную [RFC1994] систему аутентификации туннеля в процессе установления \управляющего соединения. Если LAC или LNS хочет идентифицировать партнера, с которым контактирует или контактировал посредством AVP приглашения, включенного в SCCRQ или SCCRP-сообщения. Если в SCCRQ или SCCRP получена AVP приглашения, AVP отклика приглашения должна быть послана в следующем SCCRP или SCCCN, соответственно. Если ожидаемый отклик партнера не соответствует полученному, установление туннеля должно быть запрещено.
При участии в аутентификации туннеля LAC и LNS должны обладать общим секретным кодом. Это тот же секретный код, который использовался для AVP-сокрытия (смотри раздел 4.3).
5.2. Установление сессии
После успешного установления управляющего соединения, могут формироваться индивидуальные сессии. Каждая сессия соответствует одному PPP информационному потоку между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является асимметричным в отношении LAC и LNS. LAC запрашивает LNS доступ к сессии для входных запросов, а LNS запрашивает LAC запустить сессию для работы с исходящими запросами.
5.2.1. Установление входящего вызова
Для установления сессии используется обмен тремя сообщениями. Типичным является ниже приведенный обмен:
LAC LNS
(Обнаружен вызов)
ICRQ ->
5.2.2. Установление исходящего вызова
Для установления сессии используется обмен тремя сообщениями. Типичным является ниже приведенный обмен:
LAC LNS
(Выполнить операцию вызова)
OCCN ->
5.3. Переадресация кадров PPP
Когда туннель сформирован, PPP-кадры от удаленной системы, получаемые LAC, освобождаются от CRC, канальных заголовков, и т.д., инкапсулированных в L2TP, и переадресуются через соответствующий туннель. LNS получает L2TP-пакет, и обрабатывает инкапсулированный PPP-кадр, как если бы он был получен через локальный интерфейс PPP.
Отправитель сообщения, ассоциированный с определенной сессией и туннелем, помещает ID сессии и туннеля (специфицированные партнером) в соответствующие поля заголовка всех исходящих сообщений. Таким способом, PPP-кадры мультиплексируются и демультиплексируются через общий туннель для данной пары LNS-LAC. Для заданной пары LNS-LAC может быть реализовано несколько туннелей, а для любого туннеля несколько сессий.
Значение 0 для ID-сессии и ID-туннеля является зарезервированным и не должно использоваться в качестве ID-сессии или ID-туннеля. Для случаев, когда ID-сессии еще не присвоен партнером (т.e., в процессе установления новой сессии или туннеля), поле ID-сессии должно содержать 0, а для идентификации сессии должна использоваться AVP ID-сессии сообщения. Аналогично, для случаев, когда ID-туннеля еще не присвоен партнером, ID-туннеля должен быть присвоен 0, а для идентификации туннеля должна использоваться AVP ID-туннеля.
5.4. Использование порядковых номеров в канале данных
Порядковые номера определены в заголовке L2TP для управляющих сообщений и опционно для информационных (смотри раздел 3.1). Они используются для организации надежной транспортировки управляющих сообщений (смотри раздел 5.8) и опционно информационных сообщений.
Каждый партнер поддерживает отдельную нумерацию для управляющего соединения и для каждой информационной сессии в пределах туннеля.
В отличие от канала управления L2TP, информационный канал L2TP не использует нумерацию сообщений для повторной пересылки. Скорее информационные сообщения могут использовать порядковые номера для детектирования потерь пакетов и/или восстановления исходной последовательности пакетов, которые могут быть перемешаны при транспортировке. LAC может потребовать, чтобы порядковые номера присутствовали в информационных сообщениях, посредством AVP необходимого упорядочения (смотри раздел 4.4.6). Если эта AVP присутствует при установлении сессии, порядковые номера должны присутствовать всегда. Если эта AVP отсутствует, упорядочивание сообщений находится под управлением LNS. Сервер LNS управляет разрешением и запрещением использования порядковых номеров путем посылки информационных сообщений с или без порядковых номеров на протяжении всей сессии. Таким образом, если LAC получает информационное сообщение без порядкового номера, он должен прекратить посылку сообщений с порядковыми номерами. Если LAC получает информационное сообщение с порядковым номером, он должен начать посылку информационных сообщений с порядковыми номерами. Если LNS разрешает нумерацию сообщений после предыдущего запрещения в ходе сессии, порядковые номера устанавливаются в соответствии с состоянием их последнего применения.
LNS может инициировать запрет нумерации сообщений в любое время в ходе сессии (включая первое информационное сообщение). Рекомендуется, чтобы для соединений, где возможна потеря или изменение порядка пакетов, нумерация сообщений была всегда разрешена. Запрещение нумерации возможно, только когда риск ошибки считается приемлемым. Например, если PPP-сессия при туннелировании не использует каких-либо посторонних протоколов или сжатия данных и работает только с IP (как это определено в ходе процедуры инициализации), тогда 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 ->
(Clean up)
| (Clean up) |
Разрыв контрольного соединения может быть инициирован LAC или LNS и выполняется путем посылки одного управляющего сообщения StopCCN. Получатель StopCCN должен послать ZLB ACK, чтобы подтвердить получение сообщения, и поддерживает состояние управляющего соединения на уровне достаточном для корректного приема StopCCN, а также повторения цикла, если ZLB ACK потеряно. Рекомендуемое время повторения цикла равно 31 секунде (смотри раздел 5.8). Ниже приводится типовой обмен управляющими сообщениями:
LAC или LNS LAC или LNS
StopCCN ->
(Clean up)
| (Wait) | |
| (Clean up) |
5.8. Надежная доставка управляющих сообщений
L2TP обеспечивает нижний уровень надежного транспорта для всех управляющих сообщений.
Поля Nr и Ns заголовка управляющего сообщения (смотри раздел 3.1) относятся к этому транспорту. Функции верхнего уровня L2TP не занимаются повторной пересылкой или упорядочением управляющих сообщений. Надежный управляющий канал обеспечивается за счет специального протокола, например, TCP, поддерживающего повторную пересылку управляющих сообщений и контроль перегрузки. Каждый партнер поддерживает независимую нумерацию сообщений для управляющего канала в туннеле.
Порядковые номера сообщений Ns начинаются с 0. Каждое последующее сообщение имеет номер на 1 больше, чем предыдущее. Номер по порядку, таким образом, является простым счетчиком, работающим по модулю 65536. Порядковый номер в заголовке полученного сообщения рассматривается меньше или равным последнему полученному числу, если его значение лежит в интервале между последним полученным кодом и предыдущими 32767 включительно. Например, если последний полученный номер был равен 15, тогда сообщения с порядковыми номерами 0 - 15, а также 32784 - 65535, будут рассматриваться как сообщение с меньшим или равным номером. Такое сообщение будет рассматриваться как дубликат уже полученного и не будет обрабатываться. Однако, для того чтобы гарантировать, что все сообщения подтверждены корректно (в частности в случае потери сообщения ZLB ACK), получение сообщения-дубликата должно быть подтверждено. Это подтверждение может быть реализовано косвенно, или непосредственно через ZLB ACK.
Все управляющие сообщения в пространстве номеров занимают одну нишу, за исключением подтверждения ZLB. Таким образом, Ns не инкрементируется после посылки сообщения ZLB.
Номер последнего полученного сообщения, Nr, используется для подтверждения сообщений, принятых L2TP-партнером. Этот код должен содержать порядковый номер сообщения, которые партнер ожидает получить следующим (например, последний Ns сообщения (non-ZLB) плюс 1, по модулю 65536). В то время как Nr в полученном ZLB используется для удаления сообщений из локальной очереди сообщений, ждущих imes повторной передачи в локальной очереди (смотри ниже), Nr следующего сообщения не должен обновляться при получении Ns ZLB.
Протокол надежной доставки принимающего партнера ответственен за проверку того, что управляющие сообщения доставлены на верхний уровень в правильном порядке и без дублирования. Сообщения, пребывающие в неверном порядке, могут быть занесены в очередь для последующей корректной доставки, когда пропущенные сообщения будут получены, или они могут быть выброшены, что вынудит партнера послать их повторно. Каждый туннель поддерживает очередь управляющих сообщений, которые нужно передать его партнеру. Сообщение в начале очереди посылается с заданным значением Ns, и хранится до тех пор, пока не придет от партнера управляющее сообщение, в котором поле Nr указывает на то, что данное сообщение получено. Если в течение определенного времени (рекомендуемое значение равно 1 секунде) отклика не получено, сообщение посылается повторно. Повторно посылаемое сообщение имеет то же значение Ns, но величина Nr должна быть сделана равной номеру очередного ожидаемого сообщения.
Каждая повторная посылка сообщения должна реализовываться по истечении задержки, величина которой возрастает экспоненциально от раза к разу. Таким образом, если первая повторная передача происходит спустя 1 секунду, следующая повторная передача может производиться по истечении 2 секунд, затем 4 секунд, и т.д.. Программная реализация может установить верхний предел на время между повторными пересылками сообщения. Этот предел должен быть не меньше 8 секунд. Если после нескольких повторных посылок, не зафиксировано никакого отклика от партнера, (рекомендуемое число попыток равно 5, но должно быть настраиваемым), туннель и все сессии должны быть аннулированы.
Когда туннель закрывается не по причине обрыва соединения, состояние и механизм надежной доставки должны поддерживаться и работать в течение всего периода повторных передач.
Механизм скользящего окна используется для передачи управляющих сообщений. Рассмотрим двух партнеров A & B. Предположим A задает размер приемного окна в сообщениях SCCRQ или SCCRP равным N. B при этом позволено иметь до N ожидающих подтверждения получения сообщений.
Когда N послано, нужно ждать подтверждения, которое сдвинет окно, прежде чем посылать новое управляющее сообщение. Программная реализация может поддерживать приемное окно с размером 1 (т.e., посылать AVP размера приемного окна со значением 1), но должно воспринимать от своего партнера окна с шириной до 4 (например, имеет возможность послать 4 сообщения, прежде чем остановиться и ожидать отклика). Значение 0 для AVP размера приемного окна является недопустимым.
При повторной передаче управляющих сообщений следует использовать медленный старт и окно подавления перегрузки. Рекомендуемая процедура для этого описана в приложении A.
Партнер не должен отказываться подтверждать сообщения, в качестве меры управления потоком управляющих сообщений. Предполагается, что реализация L2TP способна работать с входными управляющими сообщениями, возможно реагируя с ошибками, отражающими невозможность выполнения запрашиваемых действий. В приложении B представлены примеры управляющих сообщений, подтверждений и повторных передач.
6. Протокольная спецификация контрольного соединения
Следующие сообщения управляющего соединения используются для установления, ликвидации и поддержания L2TP-туннелей. Вся информация посылается в порядке, определенном для сети (старший октет первый). Любые "резервные" или "пустые" поля для обеспечения протокольной масштабируемости должны содержать 0.
6.1. Start-Control-Connection-Request (SCCRQ)
Start-Control-Connection-Request (SCCRQ) является управляющим сообщением, используемым для инициализации туннеля между LNS и LAC. Оно посылается LAC или LNS в процессе установления туннеля. Следующие AVP должны присутствовать в SCCRQ:
AVP типа сообщения (Message Type AVP)
Версия протокола (Protocol Version)
Имя ЭВМ (Host Name)
Возможности кадрового обмена (Framing Capabilities)
Присвоенный туннелю ID (Assigned Tunnel ID)
Следующие AVP могут присутствовать в SCCRQ:
Возможности канала (Bearer Capabilities)
Размер премного окна (Receive Window Size)
Приглашение (Challenge)
Арбитр конфликта (Tie Breaker)
Фирменная версия (Firmware Revision)
Имя производителя (Vendor Name)
6.2. Start-Control-Connection-Reply (SCCRP)
Start-Control-Connection-Reply (SCCRP) является управляющим сообщением, посланным в ответ на сообщение SCCRQ. SCCRP используется для индикации того, что SCCRQ было принято и установление туннеля должно быть продолжено. Следующие AVP должны присутствовать в SCCRP:
Тип сообщения (Message Type)
Версия протокола (Protocol Version)
Framing Capabilities
Имя ЭВМ (Host Name)
Присвоенный туннелю ID (Assigned Tunnel ID)
Следующие AVP могут присутствовать в SCCRP:
Возможности несущего канала (Bearer Capabilities)
Фирменная версия (Firmware Revision)
Имя производителя (Vendor Name)
Размер приемного окна (Receive Window Size)
Приглашение (Challenge)
Отклик на приглашение (Challenge Response)
6.3. Start-Control-Connection-Connected (SCCCN)
Start-Control-Connection-Connected (SCCCN) является управляющим сообщением, посылаемым в ответ на SCCRP. SCCCN завершает процесс установления туннеля.
| Следующее AVP должно присутствовать в SCCCN: | Message Type |
| Следующее AVP может присутствовать в SCCCN: | Challenge Response |
6.4. Stop-Control-Connection-Notification (StopCCN)
Stop-Control-Connection-Notification (StopCCN) является управляющим сообщением, посылаемым LAC или LNS для информирования своего партнера о том, что туннель закрывается (shutdown) и управляющий канал должен быть разорван. Кроме того, все активные сессии закрываются (без посылки каких-либо управляющих сообщений). Причина для отправки этого запроса указывается в AVP кода результата. Явно отклик на это сообщение не посылается, используется отклик ACK, который используется для обеспечения надежной связи для управляющего соединения транспортного уровня
Следующие AVP должны присутствовать в StopCCN:
Тип сообщения (Message Type)
Присвоенный туннелю ID (Assigned Tunnel ID)
Результирующий код (Result Code)
6.6. Запрос входящего вызова ICRQ (Incoming-Call-Request)
Incoming-Call-Request (ICRQ) является управляющим сообщением, посылаемым LAC к LNS, когда зарегистрирован входящий вызов. Это первое из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля.
ICRQ используется для индикации того, что для данного вызова должна быть установлена сессия между LAC и LNS, и предоставляет LNS параметры сессии. LAC может отложить ответ на вызов, до тех пор пока он не получит ICRP от LNS, указывающий, что должна быть запущена сессия. Этот механизм позволяет LNS получить достаточно информации о вызове, прежде чем будет определено, следует ли на него отвечать. В качестве альтернативы LAC может ответить на вызов, согласовать аутентификацию LCP и PPP, и использовать информацию, полученную для выбора LNS. В этом случае, к моменту получения сообщения ICRP на вызов уже получен ответ; в этом случае LAC просто разыгрывает шаги "call indication" и "call answer". Следующие AVP должны присутствовать в ICRQ:
Тип сообщения
ID, Присвоенный сессии (Assigned Session ID)
Call Serial Number
Следующие AVP могут присутствовать в ICRQ:
Тип носителя (Bearer Type)
ID физического канала (Physical Channel ID)
Вызывающий номер (Calling Number)
Вызванный номер (Called Number)
Субадрес (Sub-Address)
6.7. Отклик входящего вызова ICRP (Incoming-Call-Reply)
Incoming-Call-Reply (ICRP) является управляющим сообщением, посылаемым LNS к LAC в ответ на полученное сообщение ICRQ. Он является вторым из трех сообщений обмена, используемых для установления сессии в пределах L2TP туннеля.
ICRP используется для индикации того, что ICRQ успешен, и для LAC, чтобы ответить на вызов, если это еще не было сделано. Оно позволяет также LNS индицировать необходимые параметры для L2TP-сессии. Следующие AVP должны присутствовать в ICRP:
Тип сообщения (Message Type)
ID, присвоенный сессии (Assigned Session ID)
6.8. Incoming-Call-Connected (ICCN)
Incoming-Call-Connected (ICCN) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение ICRP.
Оно является третьим сообщением из трех сообщений обмена, используемых для установления сессий в пределах L2TP-туннеля.
ICCN используется для индикации того, что ICRP принято, на вызов получен ответ, а L2TP-сессия должна перейти в состояние “установлена”. Оно также предоставляет дополнительную информацию LNS о параметрах, используемых для вызова, на который получен ответ (параметры, которые не всегда быть доступны в момент посылки ICRQ).
Следующие AVP должны присутствовать в ICCN:
Тип сообщения (Message Type)
Скорость обмена в канале ((Tx) Connect Speed)
Тип кадрового обмена (Framing Type)
Следующие AVP могут присутствовать в ICCN:
Initial Received LCP CONFREQ
Последнее посланное LCP CONFREQ
Последнее полученное LCP CONFREQ
Тип Proxy Authen
Имя Proxy Authen
Приглашение Proxy Authen
Прокси Authen ID
Отклик прокси Authen
ID частной группы
Скорость обмена соединения (Rx Connect Speed)
Необходима нумерация (Sequencing Required)
6.9. Запрос исходящего вызова OCRQ (Outgoing-Call-Request)
Outgoing-Call-Request (OCRQ) является управляющим сообщением, посылаемым от LNS к LAC для индикации того, что необходимо осуществить исходящий вызов LAC. Оно является первым сообщением из трех, которые используются для установления сессии в пределах L2TP-туннеля.
OCRQ используется для индикации того, что сессия для данного вызова между LNS и LAC установлена и предоставляет LAC параметры L2TP-сессии и вызова.
LNS должен получить от LAC AVP Bearer Capabilities (возможностей носителя) на фазе установления туннеля, для того чтобы послать LAC исходящий вызов. Следующие AVP должны присутствовать в OCRQ:
Тип сообщения (Message Type)
ID, присвоенное сессии (Assigned Session ID)
Call Serial Number
Минимальный BPS
Максимальный BPS
Тип несущего канала (Bearer Type)
Тип кадрового обмена (Framing Type)
Телефонный номер адресата (Called Number)
| Следующие AVP могут присутствовать в OCRQ: | Sub-Address |
Сообщение Outgoing-Call-Reply (OCRP) является управляющим сообщением, посылаемым от LAC к LNS в ответ на полученное сообщение OCRQ.
Оно является вторым из трех сообщений, которые используются при установлении сессии в L2TP-туннеле. OCRP используется для индикации того, что LAC может попытаться послать исходящий вызов и вернуть определенные параметры, относящиеся к попытке вызова. Следующие AVP должны присутствовать в OCRP:
Тип сообщения (Message Type)
Assigned Session ID
| Следующие AVP могут присутствовать в OCRP: | Physical Channel ID |
Сообщение Outgoing-Call-Connected (OCCN) является управляющим сообщением, посылаемым от LAC к LNS, следом за OCRP, и после того как исходящий вызов завершен. Это завершающее сообщение из трех, используемых при установлении сессии в пределах L2TP-туннеля.
OCCN используется для индикации того, что результат запрошенного исходящего вызова положителен. Оно также предоставляет LNS информацию об определенных параметрах, полученных после реализации вызова. Следующие AVP должны присутствовать в OCCN:
Тип сообщения (Message Type)
Скорость обмена ((Tx) Connect Speed)
Тип кадрового обмена (Framing Type)
Следующие AVP могут присутствовать в OCCN:
Скорость обмена (Rx Connect Speed)
Необходима нумерация (Sequencing Required)
6.12. Call-Disconnect-Notify (CDN)
Сообщение Call-Disconnect-Notify (CDN) является L2TP управляющим сообщением, посылаемым LAC или LNS с целью запроса разрыва соединения для определенного вызова в пределах туннеля. Его целью является информирование партнера о рассоединении и причине разрыва соединения. Партнер должен освободить все ресурсы, и не посылать сообщений о причине данной операции.
Следующие AVP должны присутствовать в CDN:
Message Type
Код результата (Result Code)
Assigned Session ID
| Следующие AVP могут присутствовать в CDN: | Код причины Q.931 |
Сообщение WAN-Error-Notify является L2TP управляющим сообщением, посылаемым от LAC к LNS для индикации условий ошибки WAN (условия, которые реализовались в интерфейсе, поддерживающим PPP). Счетчики в этом сообщении являются накопительными.
Это сообщение должно посылаться, только когда произошла ошибка, и не чаще чем раз в 60 секунд. Счетчики сбрасываются, когда реализуется новый вызов. Следующие AVP должны присутствовать в WEN:
Тип сообщения (Message Type)
Ошибки вызова (Call Errors)
6.14. Set-Link-Info (SLI)
Сообщение Set-Link-Info является управляющим сообщением L2TP, посланным от LNS к LAC для установления согласуемых опций PPP. Эти опции можно изменять в любое время на протяжении реализации вызова, таким образом, LAC должен быть способен обновлять свою собственную информацию вызова и поведение на протяжении активной PPP-сессии. Следующие AVP должны присутствовать в SLI:
Тип сообщения (Message Type)
ACCM
7. Машины состояний управляющего соединения
Управляющие сообщения, определенные в разделе 6 пересылаются в соответствии с таблицами состояний, описанными в данном разделе. Таблицы определены для входящих вызовов, исходящих вызовов, а также для инициации самого туннеля. Таблицы состояний не задают таймауты и поведение при повторной передаче, так как это определяется механизмами, рассмотренными в секции 5.8.
7.1. Протокольные операции контрольного соединения
Этот раздел описывает работу различных функций управляющего соединения L2TP и сообщения управляющего соединения, которые используются для их поддержания.
Получение некорректного или неправильно сформатированного управляющего сообщения должно регистрироваться соответствующим образом, а управляющее соединение возвращается в исходное состояние, чтобы гарантировать восстановление заданного состояния. Управляющее соединение может затем перезапуститься инициатором операции.
Некорректное управляющее сообщение определяется как сообщение, которое содержит тип сообщения, помеченное как обязательное (смотри раздел 4.4.1) и неизвестное программе управляющее сообщение, которое получено в правильной последовательности (например, в ответ на SCCRQ послано SCCCN).
Примеры управляющих сообщений с некорректным форматом включают те, которые имеют неверное значение в своем заголовке, содержат AVP, сформированную некорректно или чье значение находится вне допустимых пределов, или сообщение, которое не имеет необходимого AVP.
Управляющее сообщение с некорректным заголовком должно быть отброшено. Управляющее сообщение с некорректным AVP должно проверить M-бит для этого AVP, чтобы определить, является ли ошибка исправимой или нет.
Неверно сформатированное, но исправимое необязательное (M-бит равен нулю) AVP в управляющем сообщении должно рассматриваться, также как нераспознанное необязательное AVP. Таким образом, если получена AVP с неверным форматом и битом M=1, сессия или туннель должны быть разорваны с соответствующим кодом результата или ошибки. Если M-бит не равен 1, AVP должно игнорироваться (за исключением записи об ошибке в местном журнале).
Это не должно рассматриваться, как разрешение посылать неверно сформатированные AVP, а лишь как указание на то, как реагировать на неверно сформатированное сообщение в случае его получения. Невозможно перечислить все возможные ошибки в сообщениях и дать совет, как с ними обходиться. Примером исправимой неверно сформатированной AVP может быть случай, когда получена AVP скорости соединения Rx, атрибут 38, с полем длина 8, а не 10 и BPS с двумя, а не четырьмя октетами. Так как Rx Connect Speed не является обязательным, такое условие не может рассматриваться как катастрофическое. Как таковое, управляющее сообщение должно быть воспринято, как если бы AVP не было получено (за исключением записи в локальный журнал ошибок). В нескольких случаях в последующих таблицах, посылается протокольное сообщение, а затем случается "сброс". Заметим, что, несмотря на ликвидацию туннеля одним из партнеров, в течение определенного времени механизм надежной доставки должен быть сохранен (смотри раздел 5.8) вплоть до окончательного закрытия туннеля. Это позволяет сообщениям управления туннеля надежно доставляться партнеру.
7.2. Состояния контрольного соединения
Протокол управляющего соединения L2TP не отличим от LNS и LAC, но различен для отправителя и получателя. Партнером инициатором является тот, кто первым формирует туннель (в конфликтной ситуации, это победитель).
Так как LAC или LNS может быть инициатором, может произойти столкновение. Смотри Tie Breaker AVP в разделе 4.4.3, где описано разрешение такого конфликта.
7.2.1. Установление контрольного соединения
Состояние |
Событие | Действие | Новое состояние |
| Idle | Local Open request | Послать SCCRQ | wait-ctl-reply |
| Idle | Получить SCCRQ, приемлемо |
Послать SCCRP | wait-ctl-conn |
| idle | Получить SCCRQ, не приемлемо |
Послать StopCCN, Clean up |
idle |
| idle | Получить SCCRP |
Послать StopCCN Clean up |
idle |
| Idle | Получить SCCCN | Clean up | idle |
| wait-ctl-reply | Получить SCCRP, приемлемо |
Послать SCCCN, Послать tunnel-open ожидающей сессии |
established |
| wait-ctl-reply | Получить SCCRP, не приемлемо |
Послать StopCCN, Clean up |
idle |
| wait-ctl-reply | Получить SCCRQ, проигрыш tie-breaker |
Clean up, Re-queue SCCRQ для состояния idle |
idle |
| wait-ctl-reply | Получить SCCCN | Послать StopCCN Clean up |
idle |
| wait-ctl-conn | Получить SCCCN, приемлемо |
Послать tunnel-open ожидающей сессии |
established |
| wait-ctl-conn | Получить SCCCN, не приемлемо |
Послать StopCCN, Clean up |
idle |
| wait-ctl-conn | Получить SCCRP, SCCRQ |
Послать StopCCN, Clean up |
idle |
| Established | Local Open request (новый вызов) |
Послать tunnel-open ожидающей сессии |
established |
| Еstablished | Административное закрытие туннеля |
Послать StopCCN Clean up |
idle |
| Established | Получить SCCRQ, SCCRP, SCCCN |
Send StopCCN Clean up |
idle |
| Idle wait-ctl-reply, wait-ctl-conn, established |
Получить StopCCN | Clean up | idle |
Idle (пассивно)
Инициатор и получатель начинают функционирование из этого состояния. Инициатор посылает SCCRQ, в то время как получатель остается в пассивном состоянии вплоть до получения SCCRQ.
wait-ctl-reply (ожидание управляющего отклика)
Инициатор проверяет, не поступил ли запрос на установление еще одного соединения от того же самого партнера, и если это так, реагирует на столкновение, как это описано в разделе 5.8.
Когда получено SCCRP, оно проверяется на совместимость версии. Если версия отклика ниже версии посланного запроса, должна использоваться более старая (низшая) версия. Если версия отклика более ранняя, и она поддерживается, инициатор переходит в состояние “установлено”. Если версия более ранняя и не поддерживается, партнеру должно быть послано StopCCN, а инициатор переходит в исходное состояние и разрывает туннель.
wait-ctl-conn (ожидание управляющего соединения)
Состояние, когда ожидается SCCCN; после получения, проверяется отклик приглашения. Туннель оказывается установленным, или разорванным, если не прошла аутентификация.
Established (установлено)
Установленное соединение может быть аннулировано по местным причинам или в результате получения Stop-Control-Connection-Notification. В случае местного разрыва инициатор должен послать Stop-Control-Connection-Notification и ликвидировать туннель.
Если инициатор получает Stop-Control-Connection-Notification, он должен разорвать туннель.
7.3. Временные соображения
В силу того, что телефонная связь по своей природе работает в реальном времени, как LNS, так и LAC должны быть реализованы по многопроцессной схеме, такой чтобы сообщения, относящиеся к нескольким вызовам, не блокировались.
7.4. Входящие вызовы
Сообщение Incoming-Call-Request генерируется LAC, когда зарегистрирован входящий вызов (например, звонки в телефонной линии). LAC выбирает ID-сессии и порядковый номер и индицирует тип носителя вызова. Модемы должны всегда индицировать аналоговый тип вызова. Вызовы ISDN должны индицировать цифровой тип вызова, когда доступно цифровое обслуживание и используется настройка скорости обмена, и аналоговый, если применен цифровой модем. Вызывающий номер, вызываемый номер и субадрес могут быть включены в сообщение, если они доступны через телефонную сеть.
Раз LAC посылает Incoming-Call-Request, он ждет отклика от LNS, но необязательно отвечает на вызов из телефонной сети. LNS может решить не воспринять вызов если:
Если LNS решает принять вызов, он откликается посылкой Incoming-Call-Reply. Когда LAC получает Incoming-Call-Reply, он пытается подключить вызов. Последнее сообщение о подключении от LAC к LNS указывает, что статус вызова для LAC и LNS должнен перейти в состояние “установлено”. Если вызов завершается до того, как LNS успел принять его, LAC посылает Disconnect-Notify, чтобы индицировать эту ситуацию.
Когда телефонный клиент вешает трубку, LAC посылает сообщение Call-Disconnect-Notify. Если LNS хочет аннулировать вызов, он посылает сообщение Call-Disconnect-Notify и ликвидирует свою сессию.
7.4.1. Состояния LAC входящих вызовов
Состояние |
Событие | Действие | Новое состояние |
| Idle | Bearer Ring или Готов индицировать входящее соединение |
Инициировать локальное открытие туннеля | wait-tunnel |
| Idle | Получить ICCN, ICRP, CDN | Clean up | idle |
| wait-tunnel | Разрыв канала или локальный запрос закрытия | Clean up | idle |
| wait-tunnel | tunnel-open | Послать ICRQ | wait-reply |
| wait-reply | Получить ICRP, приемлемо | Послать ICCN | established |
| wait-reply | Получить ICRP, Не приемлемо |
Послать CDN, Clean up |
idle |
| wait-reply | Получить ICRQ | Послать CDN Clean up | idle |
| wait-reply | Получить CDN ICCN | Clean up | idle |
| wait-reply | Локальный запрос закрытия или потеря несущей | Послать CDN, Clean up |
idle |
| Established | Получить CDN | Clean up | idle |
| Established | Получить ICRQ, ICRP, ICCN |
Послать CDN, Clean up |
idle |
| Established | Потеря несущей или локальный запрос закрытия | Послать CDN, Clean up |
idle |
idle
LAC детектирует входящий вызов на одном из своих интерфейсов. Обычно это означает, что по аналоговой линии получены звонки или ISDN TE зарегистрировало входное сообщение Q.931 SETUP. LAC инициализирует свою машину состояния, формирующую туннель, и переходит в состояние ожидания подтверждения существования туннеля.
wait-tunnel
В этом состоянии сессия ожидает открытия соединения или верификации того, что туннель уже открыт. Как только получено уведомление о том, что туннель открыт, может быть начат обмен управляющими сообщениями сессии. Первым таким сообщением будет Incoming-Call-Request.
wait-reply
LAC получает CDN-сообщение, указывающее, что LNS не хочет воспринимать вызов и переходит назад в состояние idle
(пассивен), или получает сообщение Incoming-Call-Reply, означающее, что вызов принят, LAC посылает сообщение Incoming-Call-Connected и переходит в состояние “установлен”.
established
Через туннель передаются данные. Вызов может быть аннулирован после:
7.4.2. Состояния LNS входящих вызовов
| Состояние | Событие | Действие | Новое состояние |
| Idle | Получение ICRQ, Приемлемо |
Послать ICRP | wait-connect |
| idle | Получение ICRQ, Не приемлемо |
Послать CDN, Clean up |
idle |
| idle | Получение ICRP | Послать CDN Clean up |
idle |
| Idle | Получение ICCN | Clean up | idle |
| wait-connect | Получение ICCN Приемлемо |
Подготовиться для приема данных | established |
| wait-connect | Получение ICCN Не приемлемо |
Послать CDN, Clean up |
idle |
| wait-connect | Получение ICRQ, ICRP | Послать CDN Clean up |
idle |
| idle, wait-connect, established |
Получение CDN | Clean up | idle |
| wait-connect established |
Локальный запрос закрытия | Послать CDN, Clean up |
idle |
| established | Получение ICRQ, ICRP, ICCN | Послать CDN Clean up |
idle |
idle
Получено сообщение Incoming-Call-Request. Если запрос неприемлем, посылается Call-Disconnect-Notify LAC и LNS остается в состоянии idle. Если сообщение Incoming-Call-Request приемлемо, посылается Incoming-Call-Reply. Сессия переходит в состояние wait-connect.
wait-connect
Если сессия все еще подключена к LAC, он посылает сообщение Incoming-Call-Connected LNS, который затем переходит в состояние ”установлено”. 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, так как LAC определяет, что имеется возможность реализовать вызов, который должен быть административно авторизован. Например, разрешено ли LNS осуществлять международные телефонные вызовы? Если для исходящего вызова осуществлено соединение, LAC посылает LNS сообщение Outgoing-Call-Connected, характеризующее окончательный результат попытки вызова.
7.5.1. Состояния LAC исходящих вызовов
Состояние |
Событие | Действие | Новое состояние |
| Idle | Получение OCRQ, Приемлемо |
Послать OCRP, Open bearer |
wait-cs-answer |
| idle | Получение OCRQ, Не приемлемо |
Послать CDN, Clean up |
idle |
| idle | Получение OCRP | Послать CDN Clean up |
idle |
| Idle | Получение OCCN, CDN | Clean up | idle |
| wait-cs-answer | Bearer answer, framing detected |
Послать OCCN | established |
| wait-cs-answer | Bearer failure | Послать CDN, Clean up |
idle |
| wait-cs-answer | Получение OCRQ, OCRP, OCCN |
Послать CDN Clean up |
idle |
| Established | Получение OCRQ, OCRP, OCCN |
Послать CDN Clean up |
idle |
| wait-cs-answer, established | Получение CDN | Clean up | idle |
| established | Потеря несущей, локальный запрос закрытия |
Послать CDN, Clean up |
idle |
/p> Состояниями, ассоциированными с LAC, для исходящих вызовов являются:
idle
Если Outgoing-Call-Request получен с ошибкой, посылается отклик Call-Disconnect-Notify. В противном случае, выделяется физический канал и посылается Outgoing-Call-Reply. Производится исходящий вызов и LAC переходит в состояние wait-cs-answer.
wait-cs-answer
Если вызов не завершен или произошел таймаут ожидания завершения вызова, посылается Call-Disconnect-Notify с соответствующими кодами ошибки и происходит переход в состояние idle. Если устанавливается соединение с коммутацией каналов и зафиксирован обмен кадрами, посылается Outgoing-Call-Connected, отмечающий успешную реализацию вызова и LAC переходит в состояние “установлено”.
established
Если LAC получил Call-Disconnect-Notify, вызов должен быть аннулирован через соответствующий механизм и сессия закрыта. Если вызов аннулирован клиентом или интерфейсом, через который был осуществлен вызов, должно быть послано LNS сообщение Call-Disconnect-Notify. Отправитель сообщения Call-Disconnect-Notify переходит в состояние idle.
7.5.2. Состояние исходящего вызова LNS
| Состояние | Событие | Действие | Новое состояние |
| Idle | Локальный запрос открытия | Инициировать локально tunnel-open |
wait-tunnel |
| idle | Получение OCCN, OCRP, CDN |
Clean up | idle |
| wait-tunnel | tunnel-open | Послать OCRQ | wait-reply |
| wait-reply | Получение OCRP, Приемлемо |
никакого | wait-connect |
| wait-reply | Получение OCRP, Не приемлемо |
Послать CDN Clean up |
idle |
| wait-reply | Получение OCCN, OCRQ | Послать CDN Clean up |
idle |
| wait-connect | Получение OCCN | none | established |
| wait-connect | Получение OCRQ, OCRP | Послать CDN Clean up |
idle |
| Idle, wait-reply, wait-connect, established |
Получение CDN, | Clean up | idle |
| established | Получение OCRQ, OCRP, OCCN |
Послать CDN Clean up |
idle |
| wait-reply, wait-connect, established |
Локальный запрос закрытия | Послать CDN Clean up |
idle |
| wait-tunnel | Локальный запрос закрытия | Clean up | idle |
idle, wait-tunnel
Когда инициирован исходящий вызов, сначала создается туннель. Когда туннель создан, посылается сообщение Outgoing-Call-Request LAC и сессия переходит в состояние 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, вызов был аннулирован по причине, указанной в кодах результата и причины; сессия возвращается в состояние idle. Если LNS решает завершить сессию, он посылает LAC сообщение Call-Disconnect-Notify и затем переводит сессию в исходное состояние idle.
7.6. Ликвидация туннеля
Разрыв туннеля происходит в случае посылки партнером сообщения Stop-Control-Connection-Notification. Отправитель этого уведомления должен ждать определенное время отклика на это сообщение, прежде чем ликвидировать управляющую информацию, имеющую отношение к туннелю. Получатель этого уведомления должен послать подтверждение получения этого сообщения и затем ликвидировать управляющую информацию.
Конкретная программная реализация может использовать определенный алгоритм принятия решения о разрыве управляющего соединения. Некоторые реализации могут оставить туннель открытым на некоторое время. Другие могут решить закрыть туннель немедленно после разрыва последнего соединения пользователей.
8. Реализация L2TP через специфическую среду
Протокол L2TP является само документируемым, работающим поверх уровня, который служит для транспортировки. Однако, необходимы некоторые детали подключения к среде, для того чтобы обеспечить совместимость различных реализаций.
8.1. L2TP через UDP/IP
L2TP использует зарегистрированный UDP-порт 1701 [RFC1700].
Весь L2TP-пакет, включая поле данных и L2TP-заголовок, пересылается внутри UDP-дейтограммы. Создатель L2TP-туннеля выбирает доступный UDP-порт ( который может быть или не быть 1701), и посылает пакет по нужному адресу места назначения с номером порта 1701. Получатель выбирает свободный номер порта в своей системе (который может быть или не быть 1701), и посылает отклик инициатору по его номеру порта и адресу. Раз номера портов отправителя и получателя определены, они должны оставаться неизменными в течение всей жизни туннеля.
Может происходить IP-фрагментация, так как L2TP-пакет путешествует через Интернет. Протокол L2TP не предпринимает каких-то специальных усилий, чтобы оптимизировать этот процесс.
По умолчанию для любых реализаций L2TP должно быть активизировано контрольное суммирование UDP как для управляющих, так и информационных сообщений. Реализация L2TP может предоставить опцию, способную блокировать контрольное суммирование UDP-дейтограмм для информационных сообщений. Рекомендуется, чтобы контрольные суммы UDP были всегда активированы для управляющих сообщений.
Порт 1701 используется как пакетами L2F [RFC2341], так и L2TP. Поле версия в каждом из заголовков может использоваться, чтобы отличить пакеты этих двух типов (L2F использует значение 1, а версия L2TP, описанная в этом документе, использует 2). Реализация L2TP, работающая в системе, которая не поддерживает L2F, должна отбрасывать все L2F-пакеты.
Для PPP-клиентов, использующих туннель L2TP-поверх-UDP/IP, PPP-связь имеет возможность менять порядок или отбрасывать пакеты. В первом случае могут нарушаться протоколы, отличные от IP и использующие для транспортировки PPP. Во втором – могут нарушаться протоколы, в которых предполагается по пакетный контроль ошибок, такой как TCP со сжатием заголовков. Контроль порядка можно осуществить, используя номера информационных L2TP-сообщений, если какой-то протокол, транспортируемый через PPP-туннель, не способен справиться с изменением порядка пакетов.
Молчаливое отбрасывание пакетов может оказаться проблематичным для некоторых протоколов.
Если в PPP разрешена надежная доставка [RFC1663], никакой выше расположенный протокол не может столкнуться с потерей пакетов. Если в L2TP разрешена нумерация пакетов, L2TP может контролировать потерю пакетов. В случае LNS, PPP и L2TP стеки присутствуют в LNS, и потеря пакета может регистрироваться, как если бы пакет получен с неверной CRC. Когда клиенты LAC и PPP физически различны, возможна аналоговая сигнализация, реализуемая путем посылки PPP-клиенту пакета с неверной контрольной суммой. Заметим, что это сильно усложнит отладку канальных программ клиента, так как статистика клиента не сможет отличить истинные ошибки транспортной среды от ошибок, инициированных LAC. Эта техника нереализуема на аппаратном уровне.
Если используется VJ-сжатие, и не разрешена ни надежная доставка в PPP, ни нумерация пакетов, каждый потерянный пакет будет приводить к вероятности 2-16 того, что сегмент TCP будет переадресован с неверным содержимым [RFC1144]. Там где вероятность потери велика, не следует использовать сжатие заголовков TCP-сегментов.
8.2. IP
При работе в IP-среде протокол L2TP должен обеспечить UDP-инкапсуляцию, описанную в 8.1. Другие конфигурации (возможно соответствующие формату со сжатием заголовков) могут быть определены и доступны в качестве конфигурируемой опции.
9. Соображения безопасности
Протокол 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 (безопасный IP) предоставляет безопасность на пакетном уровне за счет ESP и/или AH. Все управляющие и информационные пакеты L2TP в конкретном туннеле выглядят для системы Ipsec, как обычные информационные UDP/IP-пакеты.
Помимо транспортной безопасности IP, IPsec определяет режим работы, который позволяет туннелировать IP-пакеты. Шифрование и аутентификация на пакетном уровне, выполняемые режимом туннеля IPsec и средства L2TP, поддержанные IPsec предоставляют эквивалентные уровни безопасности.
IPsec определяет также средства контроля доступа, которые необходимы для приложений, поддерживающих IPsec. Эти средства позволяют фильтровать пакеты, на основе характеристик сетевого и транспортного уровней, таких как IP-адрес, порт, и т.д..
В модели L2TP-туннеля, аналогичная фильтрация выполняется на PPP- уровне или сетевом уровне поверх L2TP. Эти средства управления доступом на сетевом уровне могут быть реализованы в LNS за счет механизма авторизации, специфицированного производителем, или на сетевом уровне, используя транспортный режим IPsec точка-точка между взаимодействующими ЭВМ.
9.5. Аутентификация прокси PPP
L2TP определяет AVP, которые могут пересылаться в процессе установления сессии с целью передачи PPP аутентификационной информации, полученной в LAC, для перепроверки в LNS (смотри раздел 4.4.5). Это предполагает полное доверие между LAC и LNS. Если LNS решит использовать прокси аутентификацию, она должна быть конфигурируема, требуя нового цикла PPP-аутентификации по инициативе LNS (который может включать или нет новый раунд согласования параметров с LCP).
10. Соображения IANA
Этот документ определяет ряд "магических" числе, которые определяются IANA. Эта секция объясняет критерии, которые должна использовать IANA при присвоении дополнительных чисел в каждый из этих списков. Следующие субсекции описывают политику присвоения для пространства имен, определенных в данном документе.
10.1. Атрибуты AVP
Как это определено в разделе 4.1, AVP содержат поля ID производителя, атрибута и значения. Для ID производителя значение 0 IANA поддерживает регистр присвоенных атрибутов, а в некоторых случаях и значений. Атрибуты 0-39 присвоены согласно тому, как это описано в разделе 4.4. Остальные значения доступны для присвоения при согласовании с IETF [RFC 2434].
10.2. Значения типа сообщения AVP
Как определено в разделе 4.4.1, AVP типа сообщения (тип атрибута 0) имеет значение поддерживаемое IANA. Значения 0-16 определены в разделе 3.2, остальные - могут присваиваться по согласованию с IETF [RFC 2434]
10.3. Значения результирующих кодов AVP
Как это определено в разделе 4.4.2, результирующий код AVP (тип атрибута 1) содержит три поля. Два из них (поля кодов результата и ошибки) имеют значения, обслуживаемые IANA.
10.3.1. Значения поля кода результата
AVP кода результата может быть включено в сообщения CDN и StopCCN. Допустимые значения поля кода результата AVP зависят от значения типа сообщения AVP. Для сообщения StopCCN, значения 0-7 определены в разделе 4.4.2; для сообщения StopCCN, значения 0-11 определены в том же разделе. Оставшиеся значения поля кода результата для обоих сообщений доступны для присвоения через согласование с IETF [RFC 2434].
10.3.2. Значения поля кода ошибки
Значения 0-7 определены в разделе 4.4.2. Значения 8-32767 доступны для присвоения через согласование с IETF [RFC 2434]. Оставшиеся значения поля кода ошибки доступны для присвоения в соответствии с алгоритмом “первый пришел – первым обслужен” [RFC 2434].
10.4. Framing Capabilities & Bearer Capabilities
AVP Framing Capabilities и Bearer Capabilities (определенные в разделе 4.4.3) содержат 32-битовые маски. Дополнительные биты могут быть определены через стандартную процедуру [RFC 2434].
10.5. Значения типов прокси аутентификации AVP
AVP типа прокси Authen (тип атрибута 29) имеет ассоциированное значение, поддерживаемое IANA. Значения 0-5 определены в разделе 4.4.5, оставшиеся значения доступны для присвоения по схеме “первым пришел – первым обслужен” [RFC 2434].
10.6. Биты заголовка AVP
Имеется 4 резервных бита в заголовке AVP. Дополнительные биты должны присваиваться через стандартную процедуру [RFC 2434].
