RFC 1990 The PPP Multilink Protocol (MP)

Network Working Group                                         K. Sklower
Request for Comments: 1990            University of California, Berkeley
Obsoletes: 1717                                                 B. Lloyd
Category: Standards Track                                    G. McGregor
                                                   Lloyd Internetworking
                                                                 D. Carr
                                          Newbridge Networks Corporation
                                                            T. Coradetti
                                                       Sidewalk Software
                                                             August 1996

The PPP Multilink Protocol (MP)

Протокол PPP Multilink (MP)

PDF

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

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

Тезисы

Этот документ предлагает метод расщепления, сборки и упорядочения дейтаграмм, передаваемых через множество логических каналов данных. Исходным мотивом этой работы послужило делание воспользоваться множеством каналов ISDN, но она в равной степени применима в любой ситуации, когда две системы соединены множеством каналов PPP, включая асинхронные. Параллельная работа каналов побеспечивается с помощью новых опций и протоколов PPP [2].

Различия между имеющейся спецификацией PPP Multilink (RFC 1717) и данным документом указаны в разделе 11. Все системы, где реализованы дополнительные ограничения, заданные в этом документе, будут совместимы с реализациями RFC 1717.

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

Авторы выражают особую признательность Fred Baker изи ACC, Craig Fox из Network Systems, Gerry Meyer из Spider Systems, Dan Brennan из Penril Datability Networks, Vernon Schryver изи SGI (за всеобъемлющее обсуждение вопросов заполнения) и членам рабочих групп IP over Large Public Data Networks и PPP Extensions за полезные дискуссии по теме работы.

Оглавление

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

1. Введение

1.1. Мотивация

Интерфейсы ISDN BRI и PRI обеспечивают возможность организации одновременно множества каналов между системами. Это позволяет предоставлять пользователям полосу канала по запросу (bandwidth on demand) с дополнительной оплатой используемых ресурсов. Предыдущие предложения (например, Leifer и др., [1]) для передачи протоколов Internet по каналам ISDN ставили целью обеспечение такой возможности.

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

Существуют другие варианты, в которых предоставляется полоса по запросу, типа использования коммутируемых линий 28800 бит/с для резервирования выделенных линий или использования дополнительных X.25 SVC, в которых размер окна ограничен 2 в силу международных соглашений.

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

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

1.2. Функциональное описание

Обсуждаемый здесь метод похож на многоканальный протокол, описанный в стандарте ISO 7776 [4], но предлагает дополнительную возможность расщепления и последующей сборки пакетов, что ведет к снижению задержки и может увеличивать эффективное значение максимального размера принимаемого блока (MRU1). Кроме того, здесь не требуется подтверждений на канальном уровне, хотя поддерживается такая возможность.

Многоканальность основана на согласовании опции LCP, позволяющем системе показать своему партнеру возможность объединения множества физических каналов в одну «связку» (bundle). Использование нескольких связок может потребоваться взаимодействующим системам лишь в исключительных случаях.

Многоканальность согласуется на этапе первоначального согласования опции LCP. Система показывает своему партнеру желание использовать многоканальное соединение путем передачи опции multilink в процессе начального согласования опции LCP. Это согласование указывает перечисленные ниже свойства.

  1. Предлагающая опцию система может объединять множество физических каналов в один логический.

  2. Система может принимать модули данных вышележащего протокола (PDU2), фрагментированные с использованием описанного ниже заголовка multilink, и собирать из них исходные PDU для обработки.

  3. Система способна принимать PDU размером N октетов, где N задается как часть опции, если N превышает MRU на отдельном физическом канале.

После согласования многоканальности передающая система может отправлять PDU, инкапсулированные и/или фрагментированные с использованием заголовка multilink.

1.3. Соглашения

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

  • MUST (должно), SHALL (нужно) или MANDATORY (обязательно) — элемент является обязательным в соответствии с данной спецификацией.

  • SHOULD (следует) или RECOMMENDED (рекомендуется) — элемент в общем случае нужен, но при необходимости может быть опущен.

  • MAY (можно) или OPTIONAL (необязательно) — элемент является не обязательным и может применяться в соответствии с потребностями реализации.

2. Общий обзор

Для организации связи через канал «точка-точка» (point-to-point) каждая из сторон канала PPP должна сначала передать пакеты LCP для настройки канала данных в процессе организации соединения (Link Establishment). После того, как канал будет организован, PPP обеспечивает переход к фазе аутентификации (Authentication), в процессе которой могут применяться протоколы аутентификации для определения идентификаторов, связанных с каждой системой, подключенной к каналу.

Целью работы многоканальной системы является координация множества независимых каналов между фиксированной парой систем для организации виртуального соединения с более широкой пропускной способностью, нежели у любого из составляющих каналов. Агрегатный (композитный) канал или связка (bundle) обозначается парой идентификаторов для двух систем, соединенных множеством каналов. Идентификатор системы может включать информацию, обеспечиваемую PPP Authentication [3] и процессом согласования LCP. Группируемые в связку каналы могут быть различными физическими каналами (например, асинхронные линии), но могут также являться экземплярами мультиплексируемых соединений (например, ISDN, X.25 или Frame Relay). Каналы могут иметь различные типы (например, синхронные коммутируемые и асинхронные выделенные линии в одной связке).

Предполагается, что работу мультиканальной системы можно смоделировать как виртуальный объект канального уровня PPP, в котором пакеты, полученные по различным физическим каналам, идентифицируются как принадлежность отдельных сетевых протоколов PPP (Multilink Protocol или MP) и собираются в соответствии с информацией, представленной в заголовке фрагментации. Все пакеты, принятые через каналы, объединенные в связку, представляются одной машине обработки сетевого уровня, независимо от наличия заголовка multilink.

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

  • Нет отображения символов асинхронного управления.

  • Не используется Magic Number.

  • Не используется мониторинг качества канала (Link Quality Monitoring).

  • Компрессия адресов и полей управления.

  • Компрессия полей протокола.

  • Композитные кадры не используется.

  • Не используется заполнение с самоописанием (Self-Describing-Padding).

В соответствии с правилами RFC 1661 это означает, что реализация должна воспринимать собранные пакеты с ведущими нулями в поле протокола (Protocol) и без них. Хотя ниже явно запрещено включение полей Address и Control (обычно два байта FF 03) во фрагментируемую часть, хороший стиль программирования предполагает восприятие пакетов независимо от наличия этих байтов в соответствии со спецификацией RFC1661.

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

Естественно, для разных каналов могут быть согласованы различные варианты этих опций. Как будет показано в дальнейшем, каналы в мультиканальной связке должны согласовать самоописывающее заполнение (Self-Describing-Padding) даже в тех случаях, когда предварительно фрагментированные (pre-fragmented) пакеты недопустимо дополнять. Поскольку режим компрессии поля протокола (Protocol Field Compression) для каналов связки позволяет передающей системе включать или не включать ведущие нули по своему усмотрению, это является дополнительным механизмом генерации пакетов с четной длиной.

Согласование LCP не выполняется для самой многоканальной связки. Реализации недопустимо передавать пакеты LCP Configure-Request, Configure-Reject, Configure-Ack, Configure-Nak, Terminate-Request и Terminate-Ack через мультиканальную процедуру, а принимающая реализация должна отбрасывать такие пакеты без уведомления, не генерируя в ответ никаких пакетов PPP, но с возможностью протоколирования приема нежелательных пакетов. В отличие от этого, остальные пакеты LCP, имеющие функции управления, не связанные с изменением принятых по умолчанию параметров для пакета в целом, обрабатываются нормально. Реализация может передавать пакеты LCP Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request.

Эффективное значение MRU для элементов логического канала согласуется посредством опции LCP. Не имеет значения, инкапсулируются или нет пакеты NCP3 в мультиканальные заголовки и даже не играет роли канал, через который эти пакеты передаются после того, как канал идентифицирует себя как часть многоканальной связки.

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

Рассмотрим в качестве примера рисунок 1. Link 1 имеет согласованные сетевые уровни NL 1, NL 2 и MP между двумя системами. Затем эти системы согласуют MP через канал Link 2.

     Сетевой уровень
                    ______           ______
                   /      \         /      \
                  |  NL 1  |       |  NL 2  |
                   \______/         \______/
                     | | |             | | |
                     | | +-------------o-o-o-+
                     | +------+  +-----+ | | |
                     |        |  |       | | |
                     | +------o--o-------+ + |
                     | |      |__|_        | |
                     | |     /      \      | |
                     | |    |  MLCP  | <--- Демультиплексирование
                     | |     \______/       канального уровня
                     | |        |          | |
                     | |        | <--- Виртуальный канал
                     | |        |          | |
                     | |        +          | |
                  ___|_|        |       ___|_|
                 /      \       |      /      \
                |   LCP  |------+-----|  LCP   | <--- Демультиплексирование
                 \______/              \______/       канального уровня
                    |                      |
                  Link 1                 Link 2

Рисунок 1.


Кадры, принятые по каналу 1, демультиплексируются на канальном уровне в соответствии с идентификатором протокола PPP и могут быть переданы NL 1, NL 2 или MP. Канал 2 будет принимать кадры со всеми сетевыми протоколами, которые принимает канал 1.

Кадры, принятые MP, подвергаются дальнейшему демультиплексированию на сетевом уровне в соответствии с идентификатором сетевого протокола PPP и передаются NL 1 или NL 2. Любые кадры, принятые MP для любого другого протокола сетевого уровня, отбрасываются с использованием обычного для протокола механизма.

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

В этом параграфе описана схема отдельных фрагментов, которые являются «пакетами» в MP. Пакеты сетевого протокола сначала инкапсулируются (но не кадрируются) по обычным процедурам PPP а большие пакеты делятся на сегменты, размеры которых приемлемы для множества физических каналов. Хотя спецификация PPP разрешает это, реализациям недопустимо всключать поля Address и Control в объект, подлежащий фрагментации. Новый заголовок PPP, включающий идентификатор Multilink Protocol и заголовок Multilink, помещается перед каждым разделом (таким образом, первый фрагмент многоканального пакета в PPP будет иметь два заголовка — один для фрагмента, а следующий за ним для самого пакета).

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

При фрагментации и инкапсуляции PPP multilink используется идентификатор протокола 0x00-0x3d. Вслед за идентификатором протокола размещаются 4 байта с порядковым номером и дввумя однобитовыми полями, указывающими первый или последний фрагмент пакета. После согласования дополнительной опции PPP LCP четыре байта заголовка могут быть заменены двумя байтами с использованием для номера лишь 12 битов. Предполагается, что для полей Address, Control и Protocol ID используется сжатие. Отдельный фрагмент будет иметь формат, показанный ниже.

              +---------------+---------------+
Заголовок PPP | Address 0xff  | Control 0x03  |
              +---------------+---------------+
              | PID(H)  0x00  | PID(L)  0x3d  |
              +-+-+-+-+-+-+-+-+---------------+
Заголовок MP  |B|E|0|0|0|0|0|0|sequence number|
              +-+-+-+-+-+-+-+-+---------------+
              |      sequence number (L)      |
              +---------------+---------------+
              |        fragment data          |
              |               .               |
              |               .               |
              |               .               |
              +---------------+---------------+
PPP FCS       |              FCS              |
              +---------------+---------------+

Рисунок 2. Формат фрагмента с длинным номером.

 

              +---------------+---------------+
Заголовок PPP | Address 0xff  | Control 0x03  |
              +---------------+---------------+
              | PID(H)  0x00  | PID(L)  0x3d  |
              +-+-+-+-+-------+---------------+
Заголовок MP  |B|E|0|0|    sequence number    |
              +-+-+-+-+-------+---------------+
              |        fragment data          |
              |               .               |
              |               .               |
              |               .               |
              +---------------+---------------+
PPP FCS       |              FCS              |
              +---------------+---------------+

Рисунок 3. Формат фрагмента с коротким номером.


Флаг первого фрагмента (B) устанавливается (1) только для первого фрагмента, полученного для пакета PPP, а в остальных случаях имеет значение 0.

Флаг последнего фрагмента (E) устанавливается (1) только для последнего фрагмента, а в остальных случаях имеет значение 0. Во фрагменте могут быть установлены оба флага (B) и (E).

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

Между флагом последнего фрагмента (E) и порядковым номером размещаются резервные биты, которые в настоящее время не определены и должны иметь значение 0. Это 2 бита при использовании коротких номеров и 6 в остальных случаях.

В этом многоканальном протоколе со связкой каналов ассоциируется одна структура сборки, к контексте которой интерпретируются заголовки multilink.

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

3.1. Заполнение

Системам с поддержкой многоканального протокола следует реализовать заполнение с самоописанием (SDP4). Система, реализующая SDP, будет по определению включать опцию заполнения в свои начальные сообщения LCP Configure-Request или (для предотвращения задержки Configure-Reject) включать опцию заполнения после получения NAK с опцией.

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

Система должна гарантировать, что SDP, как описано в RFC 1570 [11], согласовано на отдельном канале до начала передачи каких-либо многоканальных пакетов, если она может дополнять пакеты, не являющиеся крайними, или будет применять протоколы сжатия или сетевые протоколы, способные пострадать от заполнения, как описано в RFC 1570. При необходимости, система, которая применяет заполнение, должна использовать LCP Configure-NAK с целью выбора Configure-Request для SDP от партнера.

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

4. Компромисс между размером буферов и потерями фрагментов

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

4.1. Обнаружение потери фрагментов

На каждом канале связки отправитель должен передавать фрагменты строго в порядке роста номеров (с учетом модуля пространства номеров). Это требование поддерживает стратегию получателя по обнаружению потери фрагментов путем сравнения порядковых номеров. Порядковые номера не сбрасываются для каждого нового пакета PPP и применяются даже для тех фрагментов, которые содержат пакет PPP целиком (флаги (B) и (E) установлены).

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

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

Потеря фрагмента детектируется, если M превышает порядковый номер фрагмента с флагом (E), который не был включен в завершенную сборку (т. е. не все фрагменты между первым фрагментом (B) и последним фрагментом (E) были получены). Это обеспечивается правилом роста порядковых номеров в связке. Обнаружение отсутствующего номера говорит о потере фрагмента.

Реализация должна предполагать, что фрагменту с флагом (B) непосредственно предшествует по порядковым номерам фрагмент с флагом (E). Таким образом, если потерян пакет с флагом (E) и пакет с номером M имеет флаг (B), реализация должна отбросить все фрагменты несобранных пакетов до M-1, но не следует на этом основании фрагменты с установленным флагом (B).

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

Фрагменты могут теряться в результате повреждения отдельных пакетов или аварийной потери канала (которая может произойти для одного направления). Данная версия многоканального протокола не требует специальных процедур для обнаружения отказавших каналов. Для достижения этой цели можно применять средства управления управления качеством канала PPP или периодически передавать эхо-запросы LCP.

Отправителям следует избегать простоя отдельных каналов для максимально быстрого определения потери фрагментов на приемной стороне, поскольку значение M не инкременитируется на бездействующих каналах incremented on idle links. Отправителям следует выполнять ротацию трафика между каналами, если трафика недостаточно для заполнения каналов с целью предотвращения бездействия.

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

Правило увеличения порядковых номеров предотвращает перераспределение фрагментов, поставленных в очередь для отказавшего канала, что не является необычным делом для реализаций ISO multilink на основе LAPB [4].

4.2. Требования к размеру буфера

Не существует какого-либо объема буферов, который гарантировал бы корректное обнаружение потери фрагментов, поскольку партнер на другой стороне может удерживать фрагмент на одном канале и отправить произвольное число фрагментов в другие каналы. Для обычного случая, когда передача идет по всем каналам, можно показать, что имеется минимальный объем буфера, ниже которого уже не будет возможности корректно детектировать потери. Этот объем зависит от относительных задержек между каналами (D[channel-i,channel-j]), скорости в каждом канале R[c], максимального размера фрагментов, разрешенного для каждого канала F[c] и общего объема буфером, распределяемого между каналами на передающей стороне.

При использовании PPP задержку между каналами можно определить с помощью запросов и откликов LCP-эхо (в случае разных скоростей в каналах это следует учитывать). «Проскальзывание» для каждого канала можно определить как пропускную способность, умноженную на задержку для этого канала по сравнению с каналом, где задержка максимальна, S[c] = R[c] * D[c,c-worst] (S[c-worst], естественно, будет 0!).

Ситуация, которая будет усугублять нарушение порядка номеров, возникает при пиковой загрузке (почти все каналы полностью заняты), когда передающий узел помещает в очередь одного канала возможное число пронумерованных пакетов, затем делает это на втором канале и т. д. Поскольку передающий узел должен буферизовать по крайней мере один фрагмент максимального размера на каждом канале (обычно будет буферизовать не меньше двух), получатель, который выделил буферы меньше S[1] + S[2] + … + S[N] + F[1] + … + F[N], будет сталкиваться с риском некорректного детектирования потери пакетов. Поэтому следует выделять буферы по крайней мере вдвое больше.

5. Расширения PPP LCP

Если нужна надежная работа через множество каналов, до начала использования протокола MP должна быть согласована надежная передача PPP Reliable Transmission [6] (по сути, ISO LAPB) на каждом канале связки.

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

Компрессия может применяться отдельно на каждом канале или для связки (как логического группового канала). Использование множества сжатых потоков в связке (т. е. отдельно для каждого канала) указывается протоколом Compression Control [5], но с дополнительным идентификатором протокола PPP.

5.1. Типы конфигурационных опций

Протокол MP использует дополнительные опции конфигурации LCP:

  • Multilink Maximum Received Reconstructed Unit (максимальный размер восстанавливаемого блока);

  • Multilink Short Sequence Number Header Format (использование коротких порядковых номеров);

  • Endpoint Discriminator (дискриминатор конечной точки)

5.1.1. Опция LCP Multilink MRRU

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 17   |   Length = 4  | Max-Receive-Reconstructed-Unit|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Опция LCP Multilink MRRU.


Присутствие этой опции LCP указывает, что передающая ее система поддерживает протокол PPP Multilink. Если опция не отвергнута, система будет считать все пакеты на этом канале, как пригодные для обработки общим протокольным модулем со всеми пакетами от того же партнера через любой другой канал, на котором была принята эта опция.

Поле Max-Receive-Reconstructed-Unit размером 2 октета задает максимальное число октетов в информационных полях восстановленных из фрагментов пакетов. Система должна быть способна принимать поле Information размером 1500 октетов во всех собранных пакетах PPP, хотя она может предпринять попытку согласования большего или меньшего значения. Значение 1500 взято из спецификации опции MRU LCP в PPP и при смене значения в будущих версиях RFC 1661, здесь будут применяться те же правила.

Система должна включать опцию LCP MRRU в каждом согласовании LCP, направленном на создание связки или присоединение к имеющейся. Если опция LCP MRRU предлагается на канале, предназначенном для добавления к имеющейся связке, система должна предлагать значение Max-Receive-Reconstruct-Unit, выбранное для этой связки.

Системе недопустимо передавать какие-либо multilink-пакеты в любой из каналов, пока ее партнер не предложил опцию MMRU LCP и не было подтверждения configure-Ack в последнем согласовании LCP на этом канале. Система может включить опцию MMRU LCP в сообщение configure-NAK, если партнер не предложил ее (если партнер в соответствии с правилами PPP не передал configure-Reject для нее).

Примечание. Значение MRRU, передаваемое в этой опции, соответствует MRU для связки, если рассматривать ее как объект PPP. Однако правила для опции Multilink MRRU отличаются от правил для LCP MRU, поскольку значение должно предлагаться при каждом согласовании LCP и подтверждение этой опции требуется до начала работы по множеству каналов.

5.1.2. Формат опции коротких порядковых номеров

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 18   |  Length = 2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Опция короткого номера.


Эта опция сообщает партнеру о желании данной реализации получать фрагменты с короткими 12-биитовыми порядковыми номерами. Когда партнер подтверждает эту опцию в configure-Ack он должен передавать все multilink-пакеты на всех каналах связки с 12-битовыми порядковыми номерами. В противном случае передается configure-Reject. Если желательно применять 12-битовые номера, эта опция должна быть согласована при организации связки и должна явно включаться в каждый последующий конфигурационный запрос LCP, когда система предполагает включить канал в связку, использующую 12-битовые номера. Если эта опция не согласовывалась в течение срока действия связки, будут использоваться 24-битовые порядковые номера.

Реализация, желающая передавать multilink-фрагменты с короткими порядковыми номерами, может включить опцию коротких номеров в configure-NAK для запроса у партнера встречного запроса на использование коротких номеров. Партнер не обязан отвечать такой опцией.

5.1.3. Опция дискриминатора конечной точки

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 19   |     Length    |    Class      |  Address ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Опция дискриминатора конечной точки.


Опция дискриминатор конечной точки (Endpoint Discriminator) указывает систему, передающую пакет. Эта опция указывает системе, что партнер на этом канале может быть таким же, как партнер на имеющемся другом канале. Если опция отличает партнера от всех других, должна создаваться новая связка из согласуемого соединения. Если опция соответствует классу и адресу одного из партнеров на существующем канале, новый канал должен присоединяться к связке, содержащей канал с таким партнером, или должна создаваться новая связка, в зависимости от дерева решений, показанного ниже, — пп. (1) — (4).

Для защищенного добавления к имеющейся связке должен использоваться протокол аутентификации PPP [3] с целью получения от партнера подлинной информации и предотвращения включения канала в имеющуюся связку на основе фальсифицированной опции дискриминатора.

Эта опция не требуется для многоканальной работы. Если система не получала опции Multilink MRRU, но получила опцию Endpoint Discriminator при отсутствии заданной вручную конфигурации многоканальной работы, реализации недопустимо предполагать многоканальную работу на основе только этой опции.

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

  1. Нет аутентификации и дискриминатора.

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

  2. Дискриминатор без проверки подлинности.

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

  3. Проверка подлинности без дискриминатора.

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

  4. Дискриминатор и проверка подлинности.

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

Опция содержит поле Class, которое определяет идентификатор адресного пространства, и поле Address, которое указывает уникальный идентификатор в этом пространстве.

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

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

Поддержка этой опции не является обязательной для каждой системы или партнера. Если опция не указана в Configure-Request, системе недопустимо создавать Configure-Nak с этой опцией при любой причине отказа. Вместо этого следует вести себя так, будто была принято опция с Class = 0, Address = 0. Если система получает Configure-Nak или Configure-Reject с этой опцией, она должна удалить опцию из всех дополнительных сообщений Configure-Request.

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

Реализация может использовать Endpoint Discriminator для поиска административных или аутентификационных записей в локальной базе данных. Такое применение опции является второстепенным и не допускается, если взамен можно использовать протокол PPP Authentication [3]. Поскольку некоторые классы позволяют партнеру создавать случайный или локально администрируемый адрес, использование опции в качестве ключа базы данных требует предварительного согласования между администраторами.

Описания субполей приведены ниже

Type

19 = для Endpoint Discriminator

Length

3 + размер поля Address

Class

Поле Class имеет размер 1 октет и задает идентификатор пространства адресов. Наиболее свежие значения поля LCP Endpoint Discriminator Class field можно найти в свежей версии документа Assigned Numbers [7]. Текущие значения указаны ниже.

0 Null Class (пустой класс).

1 Locally Assigned Address (локально назначаемый адрес).

2 Адрес IP.

3 Глобально администрируемый адрес IEEE 802.1 MAC

4 Блок PPP Magic-Number

5 Телефонный номер в сети общего пользования

Address

Поле Address содержит 1 или несколько октетов, указывающих идентификатор адреса в выбранном классе. Размер и содержимое поля зависит от значения поля Class, как показано ниже.

Класс 0 — пустой класс

Максимальный размер: 0

Этот класс используется по умолчанию, если опции нет в принятом сообщении Configure-Request.

Класс 1 — локально назначаемый адрес.

Максимальный размер: 20

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

Класс 2 — адрес IP

Фиксированный размер: 4

Адрес этого класса содержит IP-адрес хоста, как определено в [8].

Класс 3 — глобально администрируемый адрес IEEE 802.1 MAC

Фиксированный размер: 6

Адрес этого класса содержит 6 октетов IEEE 802.1 MAC в каноническом формате 802.3 [9]. Биты global/local и multicast/specific в адресе должны быть сброшены. Для локально назначенных MAC-адресов следует применять класс 1.

Класс 4 — блок PPP Magic-Number

Максимальный размер: 20

Это не адрес, а блок из 1 — 5 объединенных 32-битовых значений PPP Magic-Number [2]. Это класс служит для автоматической генерации значений, но их уникальность не гарантируется. Конечная точка должна применять один и тот же блок, пока хотя бы один канал находится в состоянии LCP Open. Выбор класса типа адресов не рекомендуется, поскольку они не гарантируют однозначности.

Отметим, что значения PPP Magic-Number используются в [2] обнаружения неожиданных соединений конечной точки с собой (loopback). Вероятность генерации двумя точками одинаковых magic-number невелика. Эта вероятность существенно снижается при повторении согласования LCP в поисках несоответствия если партнер может генерировать несогласованные значения magic-number.

Здесь значения magic-number используются для определения принадлежности двух каналов одной или разным конечным точкам. Исходящие от одной точки номера всегда будут совпадать. Вероятность совпадения номеров от разных конечных точек достаточно мала. Для уверенности в отсутствии ложных совпадений, как при обнаружении петель LCP, можно объединить в блок несколько несвязанных magic-number.

Класс 5 — номер в телефонной сети общего пользования

Максимальный размер: 15

Адрес этого класса содержит последовательность октетов, определяемую стандартом I.331 (E.164) и представляющую телефонный номер в международном формате, используемый для доступа к конечной точек через телефонную сеть общего пользования [10].

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

Когда использование протокола MP согласовано на канале Y и канал добавлен в связку, содержавшую единственный канал X, система должна передать пакет с multilink-инкапсуляцией в канал X до начала передачи таких пакетов в Y.

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

7. Закрытие каналов связки

Каналы связки могут разрываться с помощью обычных процедур PPP LCP с использованием пакетов LCP Terminate-Request и Terminate-Ack на таком канале. Поскольку предполагается, что каналы связки обычно не меняют порядок пакетов, прием подтверждения разрыва служит достаточным основанием для допущения от отсутствии потерь каких-либо пакетов мультиканального протокола.

Получение пакета LCP Terminate-Request на одном из каналов связки не препятствует работе оставшихся каналов.

Пока в связке остаются активные каналы, состояние PPP для связки сохраняется как отдельный объект. Однако если в связке остался единственный канал, а остальные были корректно закрыты (с Terminate-Ack), реализация может прекратить использование заголовков multilink.

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

8. Взаимодействие с другими протоколами

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

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

Хотя это явно не одобрялось выше, при наличии нескольких каналов, соединяющих две реализации, и желательности использования независимой нумерации для двух наборов протоколов, если они не блокируют друг друга, можно описать две мультиканальных процедуры, предполагая множество идентификаторов оконечных точек для данной системы. Каждый канал, однако, будет оставаться только в одном пакете. One could think of a physical router as housing two logically separate implementations, каждая из которых сконфигурирована независомо от другой.

Простейшим решением будет отказ от включения одного канала в пакет путем передачи пакета Configure-Reject в ответ на опцию Multilink LCP.

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

Работа этого протокола не влияет на обеспечение безопасности с помощью протоколов аутентификации PPP [3]. Для получения дополнительной информации вы можете воспользоваться приведенной ссылкой.

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

[1] Leifer, D., Sheldon, S., and B. Gorsline, «A Subnetwork Control Protocol for ISDN Circuit-Switching», University of Michigan (unpublished), March 1991.

[2] Simpson, W., Editor, «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, Daydreamer, July 1994.

[3] Lloyd, B., and W. Simpson, «PPP Authentication Protocols», RFC 1334, Lloyd Internetworking, Daydreamer, October 1992.

[4] International Organisation for Standardization, «HDLC — Description of the X.25 LAPB-Compatible DTE Data Link Procedures», International Standard 7776, 1988

[5] Rand, D., «The PPP Compression Control Protocol (CCP)», PPP Extensions Working Group, RFC 1962, June 1996.

[6] Rand, D., «PPP Reliable Transmission», RFC 1663, Novell, July 1994

[7] Reynolds, J., and J. Postel, «Assigned Numbers», STD 2, RFC 17005, USC/Information Sciences Institute, October 1994.

[8] Postel, J., Editor, «Internet Protocol — DARPA Internet Program Protocol Specification», STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

[9] Institute of Electrical and Electronics Engineers, Inc., «IEEE Local and Metropolitan Area Networks: Overview and Architecture», IEEE Std. 802-1990, 1990.

[10] The International Telegraph and Telephone Consultative Committee (CCITT), «Numbering Plan for the ISDN Area», Recommendation I.331 (E.164), 1988.

[11] Simpson, W., Editor, «PPP LCP Extensions», RFC 1570, Daydreamer, January 1994.

11. Отличия от RFC 1717

В этом разделе рассмотрены различия между данным документом и RFC 1717. Существуют ограничения, связанные с реализациями, которые отсутствуют в RFC 1717. Системы, следующие этим ограничениям, будут полностью совместимы с системами RFC 1717.

11.1. Согласование параметров мультиканала

RFC 1717 допускает использование отдельное формата с укороченными порядковыми номерами SSNHF (Short Sequence Number Header Format) или опций MRRU (Maximum Reconstructed Receive Unit — максимальный размер восстанавливаемого принятого блока) для индикации намерения согласовать мультиканал. Настоящая спецификация запрещает использование опций SSNHF самих по себе, но позволяет использовать обе упомянутые опции вместе. Все реализации, которые обеспечивают совместимость с RFC 1717 по остальным требованиям и следуют приведенному ограничению, будут совместимы с реализациями на основе RFC 1717.

11.2. Определение стартового порядкового номера

Данная спецификация требует, чтобы первый порядковый номер пакета, переданного после того, как виртуальный канал достигнет открытого состояния, был равен 0.

11.3. Принятое по умолчанию значение MRRU

В этой спецификации отсутствует принятое по умолчанию значение MRRU (оно всегда должно согласовываться с некоторыми другими значениями) и указано, что реализации должны поддерживать MRRU с такими же значениями, как принятый по умолчанию размер MRU для протокола PPP.

11.4. Запрет Config-Nak для EID

Данная спецификация запрещает использование config-Nak для EID во всех случаях.

11.5. Однородность порядковых номеров

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

11.6. Начало и прекращение использования мультиканальных заголовков

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

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

Документ явно разрешает ручную настройку множества каналов в отсутствие дискриминатора оконечной точки (Endpoint Descriminator) и любой формы аутентификации.

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

Keith Sklower

Computer Science Department

384 Soda Hall, Mail Stop 1776

University of California

Berkeley, CA 94720-1776

Телефон: (510) 642-9587

EMail: sklower@CS.Berkeley.EDU

Brian Lloyd

Lloyd Internetworking

3031 Alhambra Drive

Cameron Park, CA 95682

Телефон: (916) 676-1147

EMail: brian@lloyd.com

Glenn McGregor

Lloyd Internetworking

3031 Alhambra Drive

Cameron Park, CA 95682

Телефон: (916) 676-1147

EMail: glenn@lloyd.com

Dave Carr

Newbridge Networks Corporation

600 March Road

P.O. Box 13600

Kanata, Ontario,

Canada, K2K 2E6

Телефон: (613) 591-3600

EMail: dcarr@Newbridge.COM

Tom Coradetti

Sidewalk Software

1190 Josephine Road

Roseville, MN 55113

Телефон: (612) 490 7856

EMail: 70761.1664@compuserve.com

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

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

nmalykh@gmail.com

1Maximum receive unit.

2Protocol data unit.

3Network Control Protocol — протокол управления сетью.

4Self-Describing-Padding.

5В соответствии с RFC 3232 данный документ утратил силу. Информация доступна по ссылке. Прим. перев.




RFC 1997 BGP Communities Attribute

Network Working Group                                     R. Chandra
Request for Comments: 1997                                 P. Traina
Category: Standards Track                              cisco Systems
                                                               T. Li
                                                         August 1996

Атрибут BGP Communities

BGP Communities Attribute

PDF

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

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

Тезисы

BGP1 [1] представляет собой протокол междоменной маршрутизации, разработанный для сетей TCP/IP.

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

Целью предлагаемого метода является является упрощение управления политикой и снижение сложности сетевого управления в Internet.

Введение

BGP поддерживает правила транзита с помощью контролируемого распределения маршрутной информации. Механизмы такого контроля описаны в документе [1] и успешно используются транзитными сервис-провайдерами. Однако контроль за распространением маршрутной информации основан в настоящее время лишь на адресных префиксах IP или значении атрибута AS_PATH (или его части).

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

Определения терминов

Community (группа)

Группа адресатов с неким общим свойством.

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

Примеры

Свойство типа «NSFNET sponsored/AUP» может быть добавлено всем соответствующим AUP адресатам, которые анонсируются в NSFNET. Операторы NSFNET могут определить правило, которое будет анонсировать все маршруты (помеченные и не помеченные) к непосредственно соединенным с AUP заказчикам и только помеченные маршруты к коммерческим или внешним сайтам. Это позволит гарантировать, что по крайней мере одна сторона соответствует AUP (способ исполнения транзитных требований NSF).

В этом примере мы опустили основную мотивацию, связанную со сложностью базы данных политики маршрутизации, которая используется для генерации гигантских правил на основе префиксов и AS_PATH. Мы также не принимали во внимание задержки, вызываемые поддержкой этой базы данных в режиме out-of-band (письма в NACR, еженедельная настройка конфигурации и т. п.).

Второй пример основан на практике агрегирования. Зачастую бывает полезно анонсировать объединенный префикс и более специфичные префиксы-компоненты, которые были использованы при агрегировании, для оптимизации маршрутизации через следующий интервал («next hop» routing). Эти префиксы компоненты полезны только соседним партнерам BGP и, возможно, автономным системам соседних партнеров BGP, поэтому желательно фильтровать такую информацию.

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

Атрибут COMMUNITIES

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

Атрибут COMMUNITIES имеет код типа (Type Code) 8.

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

Значения в диапазоне от 0x0000000 до 0x0000FFFF и от 0xFFFF0000 до 0xFFFFFFFF являются зарезервированными.

Остальные значения нужно кодировать с использованием номера автономной системы в качестве двух первых октетов. Семантика двух оставшихся октетов определяется автономной системой (например, AS 690 может определить исследовательскую, учебную и коммерческую группы, которые будут использоваться для маршрутизации на базе правил в данной AS с использованием значений атрибута от 0x02B20000 до 0x02B2FFFF).

Общепринятые группы

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

NO_EXPORT (0xFFFFFF01)

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

NO_ADVERTISE (0xFFFFFF02)

Никакие маршруты, содержащие атрибут группы с таким значением, недопустимо анонсировать другим партнерам BGP.

NO_EXPORT_SUBCONFED (0xFFFFFF03)

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

Работа с атрибутами групп

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

Узел BGP, получивший маршрут без атрибута COMMUNITIES, может добавить такой атрибут при дальнейшем распространении маршрута своим партнерам.

Узел BGP, получивший маршрут с атрибутом COMMUNITIES, может изменить этот атрибут в соответствии с локальной политикой.

Агрегирование

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

Применимость

Атрибут пути COMMUNITIES может использоваться с протоколом BGP версии 2 и всеми последующими версиями, если явно не оговорено иное.

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

Вопросы безопасности не обсуждаются в этом документе.

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

Мы благодарим Vince Fuller, Sean Doran и Andrew Partan за то, что они обратили наше внимание на проблемы, которые атрибут BGP communities помогает решить. Благодарим также Yakov Rekhter за просмотр документа и конструктивные замечания

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

Paul Traina

cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

EMail: pst@cisco.com

Ravishanker Chandrasekeran

(Ravi Chandra)

cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

EMail: rchandra@cisco.com

Tony Li

EMail: tli@skat.usc.edu

Литература

[1] RFC 1771 Rekhter, Y., and T. Li, «A Border Gateway Protocol 4 (BGP-4)»3, March 1995.

[2] RFC 1965 Traina, P., «Autonomous System Confederations for BGP»4, June 1996.


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

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

nmalykh@gmail.com

1Border Gateway Protocol – протокол граничного шлюза.

2general Internet community

3Этот документ утратил силу и заменен RFC 4271. Перевод имеется на сайте http://www.protocols.ru. Прим. перев.




RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

Network Working Group                                       P. Vixie
Request for Comments: 1996                                       ISC
Updates: 1035                                            August 1996
Category: Standards Track

Механизм быстрого уведомления об изменении зоны

A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

PDF

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

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

Тезисы

В этом документе описан код операции NOTIFY для DNS, посредством которой ведущий (master) сервер извещает группу ведомых (slave) серверов о том, что хранящиеся на ведущем сервере данные изменились и ведомым серверам следует инициировать запрос для получения новой информации.

1. Обоснования и сфера документа

1.1. Медленное распространение новых и измененных данных в зоне DNS может быть обусловлено относительно большим периодом обновления для этой зоны. Преимущество редких обновлений состоит в том, что это снижает нагрузку на ведущий сервер. Но за это преимущество приходиться расплачиваться тем, что в течение достаточно продолжительного интервала после обновления зоны может сохраняться несогласованность между уполномоченными серверами (authority server) зоны.

1.2. DNS-транзакция NOTIFY позволяет ведущему серверу информировать ведомые об изменениях в зоне1 и, тем самым, снизить задержку распространения информации без возникновения нежелательного роста нагрузки на ведущий сервер. Данная спецификация позволяет уведомлять ведомые серверы лишь об изменении SOA RR2, но архитектура NOTIFY может быть расширена и на другие типы RR.

1.3. Документ умышленно включает множество ролевых определений — серверы Master (ведущий), Slave (ведомый) и Stealth (скрытый), их перечисление в NS RR, а также поле SOA MNAME. В этом смысле данный документ можно считать дополнением к [RFC1035].

2. Определения и инварианты

2.1. Определения используемых в документе терминов

Slave (ведомый)

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

Master (ведущий)

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

Primary Master (первичный ведущий)

Ведущий сервер в корне графа зависимостей для переноса зоны. Первичный ведущий сервер зоны указывается в поле SOA MNAME, а также может указываться в NS RR. По определению для зоны существует только один первичный ведущий сервер.

Stealth (скрытый)

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

Notify Set (набор [серверов] для уведомления)

Группа серверов, уведомляемых об изменениях в некой зоне. По умолчанию эта группа включает все серверы, указанные в NS RR, за исключением тех, которые указаны также в SOA MNAME. Некоторые реализации позволяют администратору сервера имен переписывать этот набор и добавлять в него элементы (например, скрытые серверы).

2.2. Серверы зоны должны быть организованы в граф зависимости так, чтобы существовал единственных первичный ведущий сервер, а все остальные серверы должны использовать перенос AXFR или IXFR с первичного ведущего сервера или с какого-либо из ведомых, который является одновременно и ведущим. Не допускается наличие петель в графе зависимостей AXFR.

3. Сообщение NOTIFY

3.1. Когда ведущий сервер обновляет одну или несколько RR, в которых могут быть заинтересованы ведомые серверы, ведущий сервер может передать измененные RR для имени, класса, типа и (необязательно) новые RDATA каждому ведомому серверу, используя протокол на основе операции NOTIFY.

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

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

3.4. Транспортным протоколом для транзакций NOTIFY будет UDP, если ведущий сервер не настроен на использование протокола TCP (например, в тех случаях, когда между ведущими и ведомыми серверами имеется межсетевой экран, который пропускает только трафик TCP, или измененная запись RR настолько велика, что не может быть передана в дейтаграмме UDP/DNS).

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

3.6. При использовании UDP ведущий сервер периодически шлет ведомому запрос NOTIFY, пока не будет превышено число попыток («таймаут»), получено сообщение ICMP о недоступности порта или получен отклик NOTIFY от ведомого сервера с соответствующими значениями идентификатора запроса, QNAME, IP-адреса отправителя, и номером порта UDP на стороне отправителя.

Примечание

Интервал между попытками и общее число повторов следует делать конфигурационными параметрами, доступными администратору сервера имен. Возможна независимая установка параметров для каждой зоны. Разумными значениями являются интервал 60 секунд (или таймаут при использовании TCP) и максимальное число попыток — 5 (для UDP). Представляется разумным использование линейного или экспоненциального роста интервала повтора в зависимости от номера попытки.

3.7. Запрос NOTIFY имеет QDCOUNT > 0, ANCOUNT >= 0, AUCOUNT >= 0, ADCOUNT >=0. Если ANCOUNT > 0, раздел answer представляет незащищенное указание в новом наборе RRset для данного <QNAME,QCLASS,QTYPE>. Ведомый сервер, получивший такое указание, волен трактовать эквивалентность этого раздела answer своим локальным данным, как индикацию того, что не нужно выполнять других действий. Если ANCOUNT = 0 или ANCOUNT > 0 и раздел answer отличается от локальных данных ведомого сервера, последнему следует обратиться к известным ему ведущим сервераv для получения новых данных.

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

Только условие «данные присутствуют и совпадают» моетт менять поведение ведомого сервера для случаев ANCOUNT > 0 и ANCOUNT = 0.

3.9. Данная версия спецификации NOTIFY не использует разделы authority и additional data, поэтому соответствующей данной спецификации реализации протокола следует устанавливать AUCOUNT = 0 и ADCOUNT = 0 при передаче запросов. В силу того, что в будущих версиях спецификации может быть (с обратной совместимостью) определено использование одного или обоих этих разделов, современным реализациям следует игнорировать эти разделы (но не все сообщение целиком), если AUCOUNT > 0 и/или ADCOUNT > 0.

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

Примечание

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

3.11. Единственным определенным в настоящий момент событием NOTIFY является изменение записи SOA RR. По завершению транзакции NOTIFY для QTYPE=SOA ведомому серверу следует поступать, как в том случае, когда для зоны, указанной в QNAME, истекло время обновления (интервал REFRESH, описанный в [RFC1035]), т. е., ему следует запросить у своих ведущих серверов записи SOA для зоны, указанной NOTIFY QNAME, и проверить значение порядкового номера (SOA SERIAL). Если полученное значение превышает локальное, следует инициировать перенос зоны (с помощью AXFR или IXFR).

Примечание

Поскольку при большой глубине графа зависимостей может существовать множество путей от первичного ведущего сервера к данному ведомому, возможно, что ведомый сервер получит NOTIFY от одного из своих ведущих, хотя некоторые из известных ему ведущих серверов этой зоны еще не обновили свои копии зоны. Следовательно, при введении запроса QUERY для SOA-записи зоны этот запрос следует направлять тому из известных ведущих серверов, от которого был получен запрос NOTIFY, а не какому-либо иному из ведущих серверов. Это отличается от требований документа [RFC1035], в котором сказано, что по истечении интервала SOA REFRESH следует запрашивать поочередно все ведущие серверы зоны3.

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

4. Детали и примеры

4.1. Сохранение данных о состоянии запросов при перезагрузке хоста не является обязательным, но будет весьма разумным способом выполнения транзакции SOA NOTIFY для каждой зоны, для которой сервер имеет полномочия, при первом запуске сервера.

4.2. Очевидно, что каждый ведомый сервер может получать несколько копий одного запроса NOTIFY — исходный запрос от первичного ведущего и по одному от каждого другого ведомого, который перенес обновленную зону и уведомляет об этом своих потенциальных партнеров. Протокол NOTIFY требует, чтобы серверы, работающие в режиме slave/master, передавали запрос только после того, как они обновят SOA RR или определят, что обновления не требуется, что на практике приводит к тому, что такие запросы могут передаваться только после успешного переноса зоны. Таким образом, за исключением случаев нарушения порядка доставки последний запрос NOTIFY, который получен любым ведомым сервером, будет указывать на самое свежее изменение. Поскольку ведомый сервер всегда запрашивает SOA и AXFR/IXFR только у известных ему ведущих серверов, он может повторять свой запрос QUERY для SOA после того, как каждый из его ведущих будет завершать обновление любой из зон.

4.3. Если ведущий сервер хочет предотвратить перенос с него обновленной зоны множеством ведомых серверов одновременно, он может задерживать на произвольное время передачу сообщения NOTIFY для каждого конкретного ведомого. Предполагается, что время задержки будет выбираться случайным образом, поэтому каждый ведомый сервер будет начинать свой перенос в разное время. Задержку в любом случае не следует делать больше SOA REFRESH.

Примечание

Для задания этой задержки следует использовать параметр, который может устанавливать каждый первичный ведущий сервер (возможно, независимо для каждой зоны). Случайные задержки в диапазоне от 30 до 60 секунд представляются подходящими для серверов, расположенных в одной локальной сети при умеренных размерах зон.

4.4. Ведомому серверу, получившему корректный запрос NOTIFY, следует откладывать действия, вызванные последующими сообщениями NOTIFY с такими же значениями <QNAME,QCLASS,QTYPE>, пока не будет завершена транзакция, вызванная первым сообщением NOTIFY. Такое отторжение дубликатов требуется для предотвращения избыточной нагрузки на ведущий сервер.

4.5 Обновление зоны на первичном ведущем сервере

Первичный ведущий сервер передает запрос NOTIFY всем серверам, указанным в его Notify Set. Запрос NOTIFY имеет следующие характеристики:

query ID:  (новое значение)
op:        NOTIFY (4)
resp:      NOERROR
flags:     AA
qcount:    1
qname:     (имя зоны)
qclass:    (класс зоны)
qtype:     T_SOA

4.6 Обновление зоны на ведомом сервере, который также служит ведущим

Как в примере параграфа 4.5 с единственным отличием в том, что Notify Set может отличаться от набора первичного ведущего сервера вследствие наличия локальных скрытых серверов.

4.7 Ведомый сервер получил от ведущего запрос NOTIFY

Когда ведомый сервер получает запрос NOTIFY от одного из своих локально заданных ведущих для зоны, указанной в QNAME, с QTYPE=SOA и QR=0, ему следует перейти в состояние, которое возникает при завершении отсчета для таймера обновления зоны. Сервер будет также возвращать отправителю запроса NOTIFY отклик NOTIFY со следующими характеристиками:

query ID:   (то же значение, что и в запросе)
op:         NOTIFY (4)
resp:       NOERROR
flags:      QR AA
qcount:     1
qname:      (имя зоны)
qclass:     (класс зоны)
qtype:      T_SOA

Этот отклик должен быть идентичен запросу NOTIFY, отличаясь от того лишь установленным битом QR. Идентификатор запроса (query ID) в отклике должен совпадать с одноименным полем вызвавшего отклик запроса.

4.8 Ведущий сервер получил от ведомого отклик NOTIFY

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

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

Мы верим, что использование NOTIFY не может порождать проблем безопасности за исключением описанных ниже.

  1. Запрос NOTIFY с подставным адресом отправителя IP/UDP может заставить ведомый сервер передать ложные запросы SOA своим ведущим, что может позволить организовать DoS-атаку, если подставные запросы передаются достаточно часто.
  2. Можно использовать подмену TCP4 для инициирования ложных запросов SOA со стороны ведомого сервера или подмену UDP/DNS для форсирования переноса зоны.

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

[RFC1035] Mockapetris, P., «Domain Names — Implementation and Specification», STD 13, RFC 1035, November 1987.

[IXFR] Ohta, M., «Incremental Zone Transfer», RFC 1995, August 1996.

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

Paul Vixie

Internet Software Consortium

Star Route Box 159A

Woodside, CA 94062

Phone: +1 415 747 0204

EMail: paul@vix.com


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

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

nmalykh@protocols.ru

1Это можно рассматривать, как прерывание в противовес режиму опроса, обычно используемому в системе DNS.

2Resource Record — запись о ресурсе. Прим. перев.

3В RFC 1035 не удалось обнаружить в явном или неявном виде такого требования. Прим. перев.

4TCP spoofing.

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




RFC 1995 Incremental Zone Transfer in DNS

Network Working Group                                        M. Ohta
Request for Comments: 1995             Tokyo Institute of Technology
Updates: 1035                                            August 1996
Category: Standards Track

Инкрементальный перенос зон в DNS

Incremental Zone Transfer in DNS

PDF

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

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

Тезисы

Этот документ вносит расширение для протоколов DNS, обеспечивающее поддержку механизма инкрементального перноса зон (IXFR1).

1. Введение

Для быстрого распространения изменений в базе данных DNS [STD13] требуется снизить ведичину задержки путем активного уведомления серверов об изменениях. Это достигается за счет добавления в DNS расширения NOTIFY [NOTIFY].

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

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

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

2. Краткое описание протокола

Если клиент IXFR, который явно имеет устаревшую версию зоны, полагает, что ему нужна новая информация о зоне (обычно по тайм-ауту обновления SOA или с помощью механизма NOTIFY), он передает сообщение IXFR, содержащее порядковый номер SOA для своей, предположительно устаревшей, копии зоны.

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

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

При получении запроса IXFR с тем же или более новым порядковым номером серверу следует передавать в ответ только порядковый номер текущей версии записи SOA, как это делается в случае AXFR.

Транспортировка запроса может осуществляться с помощью протокола UDP или TCP. Если запрос IXFR передается через UDP, сервер IXFR может попытаться ответить с помощью протокола UDP, если отклик целиком помещается в один пакет DNS. Если UDP не позволяет передать весь отклик в одном пакете, клиенту возвращается только запись SOA для текущей версии сервера, чтобы уведомить клиента о необходимости передачи запроса по протоколу TCP.

Таким образом, клиенту следует передавать первый запрос IXFR с использованием UDP. Если тип запроса не был распознан сервером, тому слеует попытаться использовать AXFR (предварительно передав по протоколу UDP запись SOA) для обеспечения совместимости с устаревшими версиями. Если отклик представляет собой один пакет или у сервера нет новой версии для данного клиента, обработка запроса на этом завершается. В остальных случаях следует предпринять попытку использования TCP IXFR.

Для обеспечения целостности серверам следует использовать контрольные суммы UDP для всех UDP-откликов. Осмотрительным клиентам следует игнорировать пакеты UDP с нулевым значением контрольной суммы и использовать взамен TCP IXFR.

Для IXFR агентство IANA выделило значение 251.

3. Формат запроса

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

4. Формат отклика

Если инкрементальный перенос зоны недоступен, возвращается зона целиком. Первая и последняя записи RR в отклике являются записями SOA для данной зоны (т. е., поведение не отличается от переноса AXFR, но в качестве типа запроса используется IXFR).

Если доступен инкрементальный перенос, возвращается одна или несколько записей о различиях. В начале и в конце последовательности различий помещается запись SOA текущей версии зоны на сервере.

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

При изменении RR сначала удаляются имеющиеся записи, а после этого добавляются измененные и новые.

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

Записи RR в инкрементальном переносе могут быть неполными. Т. е., при изменении множества однотипных RR передаваться будут только измененные записи.

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

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

5. Стратегия очистки

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

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

Информация, которая старше срока действия SOA, также может удаляться.

6. Объединение изменений

Сервер IXFR может собирать множество последовательностей различий в одну последовательность, отбрасывая данные о промежуточных изменениях.

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

Однако такое объединение может оказаться не столь полезным, если клиент IXFR имеет доступ к двум серверам IXFR с несогласованной консолидацией изменений. Текущая версия клиента IXFR, полученная от сервера A, может быть не известна серверу B. В таком случае B не сможет обеспечить инкрементальное обновление для неизвестной версии и придется переносить зону полностью.

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

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

7. Пример

Ниже приведены три версии зоны с текущим порядковым номером 3.

JAIN.AD.JP.      IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
                    1 600 600 3600000 604800)
                 IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP.   IN A 133.69.136.1
NEZU.JAIN.AD.JP. IN A 133.69.136.5

Имя NEZU.JAIN.AD.JP. удалено, а JAIN-BB.JAIN.AD.JP. добавлено.

jain.ad.jp.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
                           2 600 600 3600000 604800)
                    IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP.      IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4
                    IN A 192.41.197.2

Один из IP-адресов JAIN-BB.JAIN.AD.JP. изменен.

JAIN.AD.JP.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
                           3 600 600 3600000 604800)
                    IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP.      IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3
                    IN A 192.41.197.2

На запрос IXFR

           +---------------------------------------------------+
Заголовок  | OPCODE=SQUERY                                     |
           +---------------------------------------------------+
Вопрос     | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
           +---------------------------------------------------+
Ответ      | <пусто>                                           |
           +---------------------------------------------------+
Полномочия | JAIN.AD.JP. IN SOA serial=1                       |
           +---------------------------------------------------+
Дополнение | <пусто>                                           |
           +---------------------------------------------------+

может быть дан отклик со следующим сообщением для полного переноса зоны:

           +---------------------------------------------------+
Заголовок  | OPCODE=SQUERY, RESPONSE                           |
           +---------------------------------------------------+
Вопрос     | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
           +---------------------------------------------------+
Ответ      | JAIN.AD.JP.         IN SOA serial=3               |
           | JAIN.AD.JP.         IN NS NS.JAIN.AD.JP.          |
           | NS.JAIN.AD.JP.      IN A 133.69.136.1             |
           | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3             |
           | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2             |
           | JAIN.AD.JP. IN SOA serial=3                       |
           +---------------------------------------------------+
Полномочия | <пусто>                                           |
           +---------------------------------------------------+
Дополнение | <пусто>                                           |
           +---------------------------------------------------+

или с сообщением для инкрементального переноса:

           +---------------------------------------------------+
Заголовок  | OPCODE=SQUERY, RESPONSE                           |
           +---------------------------------------------------+
Вопрос     | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
           +---------------------------------------------------+
Ответ      | JAIN.AD.JP.         IN SOA serial=3               |
           | JAIN.AD.JP.         IN SOA serial=1               |
           | NEZU.JAIN.AD.JP.    IN A 133.69.136.5             |
           | JAIN.AD.JP.         IN SOA serial=2               |
           | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4             |
           | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2             |
           | JAIN.AD.JP.         IN SOA serial=2               |
           | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4             |
           | JAIN.AD.JP.         IN SOA serial=3               |
           | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3             |
           | JAIN.AD.JP.         IN SOA serial=3               |
           +---------------------------------------------------+
Полномочия | <пусто>                                           |
           +---------------------------------------------------+
Дополнение | <пусто>                                           |
           +---------------------------------------------------+

или с консолидированной информацией об изменениях:

           +---------------------------------------------------+
Заголовок  | OPCODE=SQUERY, RESPONSE                           |
           +---------------------------------------------------+
Вопрос     | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
           +---------------------------------------------------+
Ответ      | JAIN.AD.JP.         IN SOA serial=3               |
           | JAIN.AD.JP.         IN SOA serial=1               |
           | NEZU.JAIN.AD.JP.    IN A 133.69.136.5             |
           | JAIN.AD.JP.         IN SOA serial=3               |
           | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3             |
           | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2             |
           | JAIN.AD.JP.         IN SOA serial=3               |
           +---------------------------------------------------+
Полномочия | <пусто>                                           |
           +---------------------------------------------------+
Дополнение | <пусто>                                           |
           +---------------------------------------------------+

или (в случае переполнения пакета UDP) с сообщением:

           +---------------------------------------------------+
Заголовок  | OPCODE=SQUERY, RESPONSE                           |
           +---------------------------------------------------+
Вопрос     | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
           +---------------------------------------------------+
Ответ      | JAIN.AD.JP. IN SOA serial=3                       |
           +---------------------------------------------------+
Полномочия | <пусто>                                           |
           +---------------------------------------------------+
Дополнение | <пусто>                                           |
           +---------------------------------------------------+

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

Оригинальную идею IXFR предложили Anant Kumar, Steve Hotz и Jon Postel.

В развитие протокола и документации внесли вклад множество людей, включая Anant Kumar, Robert Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz и членов рабочей группы IETF DNSIND.

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

[NOTIFY] Vixie, P., «DNS NOTIFY: A Mechanism for Prompt Notification of Zone Changes», RFC 1996, August 1996.

[STD13] Mockapetris, P., «Domain Name System», STD 13, (RFC 1034 и RFC 1035), November 1987.

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

Хотя в DNS существуют некоторые проблемы безопасности, в данном документе не содержится попыток решения этих проблем.

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

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

Masataka Ohta

Computer Center

Tokyo Institute of Technology

2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN

Phone: +81-3-5734-3299

Fax: +81-3-5734-3415

EMail: mohta@necom830.hpcl.titech.ac.jp


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

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

nmalykh@protocols.ru

1Incremental zone transfer.

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




RFC 1982 Serial Number Arithmetic

Network Working Group                                         R. Elz
Request for Comments: 1982                   University of Melbourne
Updates: 1034, 1035                                          R. Bush
Category: Standards Track                                RGnet, Inc.
                                                         August 1996

Арифметика порядковых номеров

Serial Number Arithmetic

PDF

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

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

Тезисы

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

1. Введение

Поле порядкового номера в записи SOA определено в RFC1035 следующим образом

SERIAL – 32-битовое целое число без знака, задающее значение номера версии для оригинала зоны. При переносе зоны это значение сохраняется. Диапазон значений порядковых номеров является «циклическим2» и при сравнении значений следует использовать арифметику порядковых номеров.

RFC1034 использует такую же терминологию при определении процедур согласования для вторичного сервера зоны.

К сожалению термин «арифметика порядковых номеров» не определен ни в RFC1034 и RFC1035, ни в других упомянутых там документах.

Представляется, что в этой фразе имеется в виду арифметика, используемая для порядковых номеров TCP [RFC793], которая определена в документе [IEN-74].

К сожалению, арифметика, определенная [IEN-74], не соответствует требованиям DNS по причине отсутствия в этой арифметике операции сравнения.

Во избежание возникновения проблем в столь простой ситуации данный документ определяет операции, поддерживаемые для порядковых номеров. Это определение предназначено лишь для того, чтобы прояснить смысл RFC1034 и RFC1035 в надежде, что оно будет совместимо с существующими реализациями. Однако известно, что старые реализации трактуют порядковый номер как обычное целое число без знака без попыток реализовать тот или иной вариант «пространства порядковых номеров». В таких реализациях могут возникать проблемы при достижении максимального значения порядкового номера. Однако с этим уже ничего нельзя сделать, пока такие реализации не выйдут из употребления.

2. Арифметика порядковых номеров

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

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

Для такого использования порядковых номеров нужно задать размер пространства порядковых номеров. Этот размер, обозначаемый термином SERIAL_BITS, задается значением целочисленной степени числа 2, которое на 1 больше самого большого числа в пространстве порядковых номеров. Этот же параметр определяет число битов, которые нужны для представления всех возможных значений порядкового номера определенного типа. Операции над порядковыми номерами определены ниже.

3. Операции с порядковыми номерами

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

3.1. Добавление

Порядковые номера увеличиваются путем добавления положительного целого числа n, где значение n берется из диапазона [0 .. (2^(SERIAL_BITS — 1) — 1)]. Для порядкового номера s результат добавления s’ определяется выражением

s' = (s + n) modulo (2 ^ SERIAL_BITS)

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

Добавление к порядковому номеру значений, не входящих в диапазон [0 .. (2^(SERIAL_BITS — 1) – 1)], не определено.

3.2. Сравнение

Любые два порядковых номера s1 и s2 можно сравнить один с другим. Определение результата сравнения приводится ниже.

Рассмотрим сначала два целых числа i1 и i2 из неограниченного набора неотрицательных чисел, значения которых совпадают с s1 и s2, соответственно. Сравним теперь числа i1 и i2, используя обычную арифметику целых чисел.

Порядковые номера s1 и s2 равны между собой тогда и только тогда, когда i1 = i2. Во всех остальных случаях s1 не равен s2.

Номер s1 меньше номера s2 тогда и только тогда, когда s1 не равен s2 и выполняется любое из приведенных ниже условий

(i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) 

или

(i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))

Номер s1 больше номера s2 тогда и только тогда, когда s1 не равен s2 и выполняется любое из приведенных ниже условий

(i1 < i2 and i2 - i1 > 2^(SERIAL_BITS – 1))

или

(i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))

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

Причина неопределенности заключается в том, что любое простое определение операции сравнения, в соответствии с которым для такой пары (s1, s2) можно сказать, что s1 меньше s2, будет давать и обратный результат (s2 меньше, чем s1) при сравнении для пары (s2, s1). Это означает, что выбор порядка операндов при сравнении может изменять результат, что и приводит к неопределенности

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

s1 < s2 

но при этом

(s1 + 1) > (s2 + 1)

что вызывает интуитивное неприятие.

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

Отношения «больше или равно» и «меньше или равно» логически вытекают из приведенных выше определений.

4. Следствия

Нужно отметить некоторые следствия из приведенных выше определений.

4.1. Следствие 1

Для любого порядкового номера s и любого целого числа n выполняется отношение

(s + n) >= s.

Более того, равенство (s + n) == s выполняется только в том случае, когда n == 0, а во всех остальных случаях (s + n) > s.

4.2. Следствие 2

Если s’ является результатом прибавления ненулевого целого числа n к порядковому номеру s, а m – другое целое число из диапазона значений, которые можно прибавлять к порядковым номерам и s» является результатом добавления m к порядковому номеру s’, то невозможно однозначно утверждать, что s» больше (или меньше), чем s, хотя известно, что s» не равен s.

4.3. Следствие 3

Если продолжит увеличение номера s» из предыдущего следствия, нельзя будет предсказать результат сравнения результата с номером s.

4.4. Следствие 4

Если в следствии 2 добавление суммы (n + m) к порядковому номеру s не будет создавать неопределенного результата, тогда на основании следствия 1 можно будет сказать, что s» больше, чем s.

5. Примеры

5.1. Тривиальный случай

Простейший случай пространства порядковых номеров имеет SERIAL_BITS == 2. В этом случае пространство номеров будет включать значения 0, 1, 2 и 3 (3 == 2^SERIAL_BITS – 1).

В этом случае, максимальное число, которое можно добавлять к порядковому номеру, составляет 2^(SERIAL_BITS — 1) – 1 или просто 1.

Тогда 0+1 == 1, 1+1 == 2, 2+1 == 3, а 3+1 == 0. Далее можно сказать, что 1 > 0, 2 > 1, 3 > 2, а 0 > 3. Не существует возможности однозначного сравнения номеров для пар (2, 0) и (3, 1).

5.2. Более сложный пример

Рассмотрим более сложный случай с SERIAL_BITS == 8. В этом случае пространство порядковых номеров будет включать целые числа 0, 1, 2, … 254, 255 (255 == 2^SERIAL_BITS – 1).

Для этого случая наибольшее значение, которое можно добавлять к порядковому номеру, составляет 2^(SERIAL_BITS — 1) – 1 или 127.

Операции добавления дают вполне предсказуемые результаты – 255 + 1 == 0, 100 + 100 == 200, а 200 + 100 == 44.

Операция сравнения более интересна — 1 > 0, 44 > 0, 100 > 0, 100 > 44, 200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, а 44 > 200.

Отметим, что 100+100 > 100, но (100+100)+100 < 100. Увеличение порядкового номера может привести к тому, что номер станет “меньше”. Естественно, что при добавлении к номеру небольших значений, подобные ситуации будут происходить реже. Однако нужно помнить об этой особенности, чтобы избежать возможных ошибок или использовать ее для реального уменьшения порядкового номера.

Пары значения (0, 128), (1, 129), (2, 130) и т. д. до (127, 255) дают при сравнении неопределенный результат.

Можно (произвольно) определить, что 128 > 0, 129 > 1, 130 > 2, …, 255 > 127, несколько изменив определение оператора сравнения, приведенное выше. Однако следует отметить, что такое изменение приведет к тому, что 255 > 127, а (255 + 1) < (127 + 1), поскольку 0 < 128. Кроме того, такое определение усложняет реализацию.

6. Использование арифметики

Поскольку приведенное здесь определение арифметики порядковых номеров может оказаться полезным не только для DNS, на эту арифметику можно ссылаться как на «арифметику порядковых номеров RFC1982». Любые ссылки на использование этой арифметики должны принимать во внимание, что операции с порядковыми номерами должны соответствовать правилам, приведенным в параграфах 2 — 5.

7. Порядковый номер DNS SOA

Порядковый номер записей DNS SOA представляет собой номер, соответствующий приведенному выше определению с SERIAL_BITS = 32. таким образом, этот порядковый номер представляет собой неотрицательное целое число из диапазона [0 .. 4294967295] – 32-битовое целое число без знака.

Максимальное значение инкремента порядкового номера составляет 2147483647 (231 — 1).

Следует обратить внимание на ситуации, когда порядковый записи не обновляется достаточно долго (максимальный срок ограничен значением SOA.expire) и инкремент при следующем обновлении может превысить указанное выше значение. В этом случае некоторые вторичные серверы имен с устаревшими данными будут иметь порядковый номер “больше” обновленного значения для первичного сервера. В некоторых случаях может потребоваться даже уменьшение порядкового номера записи. Если это приходится делать, следует принять специальные меры для проверки того, что все вторичные серверы корректно восприняли порядковые номера записи основного сервера при ее последующих обновлениях.

Отметим, что во всех случаях увеличение порядкового номера должно трактоваться как начало новой последовательности увеличения номера, а также как продолжение всех предыдущих последовательностей увеличения номера, начатых в период, указанный SOA.expire.

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

8. Обновление документов

Использование арифметики порядковых номеров (sequence space arithmetic) RFC1034 и RFC1035 должно трактоваться в соответствии с определениями, приведенными в данном документе.

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

В этом документе не рассматриваются вопросы безопасности.

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

Литература

[RFC1034] Domain Names — Concepts and Facilities, P. Mockapetris, STD 133, ISI, November 1987.

[RFC1035] Domain Names — Implementation and Specification P. Mockapetris, STD 131, ISI, November 1987

[RFC793] Transmission Control protocol Information Sciences Institute, STD 71, USC, September 1981

[IEN-74] Sequence Number Arithmetic William W. Plummer, BB&N Inc, September 1978

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

Спасибо Робу Аустейну (Rob Austein) за предложения по разъяснению неопределенностей в операции сравнения и Михаэлю Паттону (Michael Patton) за его попытки найти другое решение для операции сравнения. Благодарим также членов рабочей группы IETF DNSIND 1995-6, в частности, Пола Мокапетриса (Paul Mockapetris).

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

Robert Elz

Computer Science

University of Melbourne

Parkville, Vic, 3052

Australia.

EMail: kre@munnari.OZ.AU

 

Randy Bush

RGnet, Inc.

10361 NE Sasquatch Lane

Bainbridge Island, Washington, 98110

United States.

EMail: randy@psg.com


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

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

nmalykh@gmail.com

1Domain Name System.

2В оригинале используется термин wrap.

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