RFC 8238 Data Center Benchmarking Terminology

Опубликовано 30.08.2017 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                        L. Avramov
Request for Comments: 8238                                        Google
Category: Informational                                          J. Rapp
ISSN: 2070-1721                                                   VMware
                                                             August 2017

Терминология для оценки работы ЦОД

Data Center Benchmarking Terminology

PDF

Аннотация

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

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

Документ не является спецификацией стандарта (Internet Standards Track) и публикуется с информационными целями.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Картина трафика в ЦОД неоднородна и постоянно меняется. Это обусловлено характером и разнообразием применяемых в ЦОД приложений. Это могут быть большие потоки «запад-восток» («горизонтальные» потоки между серверами одного ЦОД) в одном центре и большие потоки «север-юг» («вертикальные» потоки из внешнего источника к серверу ЦОД) в другом, а также разные комбинации направлений потоков. Картины трафика по своей природе содержат пики (всплески) и включают потоки «многие к одному» «многие ко многим», «один ко многим». Потоки могут быть небольшими и чувствительными к задержками или большими и чувствительными к пропускной способности, а также включать смесь трафика UDP и TCP. Все перечисленное может существовать в одном кластере и поток может проходить через одно сетевое устройство. Тесты производительности сетевых устройств используются достаточно давно и описаны в [RFC1242], [RFC2432], [RFC2544], [RFC2889] и [RFC3918]. Эти тесты в основном привязаны к параметрам задержки и максимальной пропускной способности тестируемого устройства (DUT3). Эти стандарты хороши для измерения теоретической максимальной пропускной способности, скорости пересылки и задержки в условиях теста, но не соответствуют реальным картинам трафика, который может проходить через сетевые устройства. Сетевые устройства ЦОД включают маршрутизаторы и коммутаторы.

Ниже перечислены основные характеристики типичных сетевых устройств.

  • Высокая плотность портов(не менее 48).

  • Высокая скорость (вплоть до 100 Гбит/с на порт).

  • Высокая пропускная способность (суммарная линейная скорость всех портов для уровня 2 и/или 3).

  • Малые задержки (микросекунды или наносекунды).

  • Незначительный объем буферов (мегабайты в объеме всего устройства).

  • Пересылка на уровнях 2 и 3 (уровень 3 не обязателен).

В этом документе приведены определения, метрические параметры и новая терминология, включая случаи перегрузки и анализа буферов в коммутаторах, а также заново определены некоторые базовые компоненты с учетом широкого спектра картин трафика. Методология тестирования определена в [RFC8239].

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

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

1.2. Формат определений

  • Определяемый термин (например, задержка).

  • Определение — конкретное определение термина

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

  • Единицы измерения — методология измерения и единицы, используемые для значения, если это применимо.

2. Задержка

2.1. Определение

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

Интервал задержки можно оценивать между разными комбинациями событий, независимо от типа коммуникационного устройства (побитовая или сквозная пересылка — cut-through или с промежуточной буферизацией — store-and-forward). В [RFC1242] задержка определяется по разному для каждого типа устройств.

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

  • FILO (First In Last Out — первый вошел — последний вышел)

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

  • FIFO (First In First Out — первый вошел — первый вышел)

    Временной интервал начинается при поступлении во входной порт конца первого бита входящего кадра и заканчивается в тот момент, когда начало первого бита выходного кадра становится видно на выходном порту. Этот вариант применяется для определенной в [RFC1242]) задержки устройств с побитовой пересылкой.

  • LILO (Last In Last Out — последний вошел — последний вышел)

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

  • LIFO (Last In First Out — последний вошел — первый вышел)

    Временной интервал начинается при поступлении во входной порт последнего бита входящего кадра и заканчивается в тот момент, когда первый бит выходного кадра становится виден на выходном порту. Этот вариант применяется для определенной в [RFC1242]) задержки устройств с промежуточной буферизацией.

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

  • FILO это FL (первый бит — последний бит).

  • FIFO это FF (первый бит — первый бит).

  • LILO это LL (последний бит — последний бит).

  • LIFO это LF (последний бит — первый бит).

Это определение в контексте оценки производительности коммутаторов ЦОД используется взамен определения «задержки», приведенного в параграфе 3.8 RFC 1242 и процитированного ниже.

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

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

Для обеспечения соответствия обоим типам сетевых устройств и двум вновь возникшим гибридным типам измерение задержки в коммутаторах в соответствии с данным документом должно основываться на событиях FILO. Этот вариант будет включать задержку в коммутаторе, а также задержку на преобразование кадра в последовательную форму (serialization delay). Это представляет «полную» задержку при прохождении через DUT. Для чувствительных к задержке приложений, которые могут работать, начиная с первых битов кадра, можно использовать события FIFO (для определение RFC 1242 для задержки в устройствах с промежуточной буферизацией). В любом случае комбинация событий, используемая для определения задержки должна указываться в отчете.

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

Как было отмечено в параграфе 2.1, FILO является наиболее значимым определением для процесса измерения.

Не все устройства DUT относятся к «чистым» типам cut-through или store-and-forward. В ЦОД используются DUT, которые часто используют промежуточную буферизацию для мелких пакетов и сквозную пересылку пакетов крупнее некого заданного размера. Размер пакета, при котором поведение изменяется, может быть настраиваемым (это зависит от производителя DUT). Определение FILO подходит как для сквозной коммутации, так и для случая промежуточной буферизации. Порог смены типа поведения не оказывает влияния на оценку работы, поскольку FILO подходит для обоих вариантов.

Механизм LIFO подходит для коммутаторов store-and-forward, но не работает при сквозной коммутации, поскольку в этом случае он будет показывать отрицательную задержку для больших пакетов за счет того, что не учитывается преобразование в последовательный формат (serialization delay). Следовательно, этот механизм недопустимо использовать при сравнении задержки разных DUT.

2.3. Единицы измерения

Ниже перечислены методы измерения, используемые при оценке производительности.

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

  2. FIFO может использоваться для некоторых приложений, способных обрабатывать данные с момента поступления первого бита — например, FPGA (Field-Programmable Gate Array).

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

3. Вариации задержки (Jitter)

3.1. Определение

В контексте ЦОД термин jitter является синонимом термина delay variation (вариации задержки). Они определяются путем многократного измерения задержки в одном направлении, как описано в RFC 3393. Обязательным для использования определением delay variation является PDV4, определенная в параграфе 4.2 [RFC5481]. При рассмотрении потока пакетов задержки все пакетов задержки всех пакетов вычитаются из минимальной задержки всех пакетов в потоке. Это упрощает оценку диапазона вариаций задержки (Max — Min) или высокого процентиля PDV (99-й для устойчивости к постороннему трафику).

При использовании для измерения задержки временных меток First-bit — Last-bit, вариации задержки должны измеряться с применением пакетов или кадров одинакового размера, поскольку определение задержки включает время преобразования каждого пакета в последовательный формат (serialization time). В остальных случаях, если используется First-bit — First-bit, ограничений на размер не накладывается.

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

В дополнение к диапазону PDV и/или высокому процентилю PDV могут использоваться межпакетные вариации задержки (IPDV5), определенные в параграфе 4.1 [RFC5481] (разность между двумя последовательными пакетами) для целей определения вариаций межпакетных интервалов (например, является поток пакетов сравнительно однородным или в нем возникают пики). Однако не следует использовать абсолютные значения IPDV, поскольку в них «сколлапсированы» пиковые и распределенные варианты потока.

3.3. Единицы измерения

Измерение вариаций задержки выражается в долях секунды. Могут также использоваться гистограммы PDV для демонстрации распределения.

4. Калибровка на физическом уровне

4.1. Определение

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

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

  • Тип устройства, используемого для генерации/измерения трафика.

  • Тип линейных карт, используемых в генераторе трафика.

  • Тип трансиверов в генераторе трафика.

  • Тип трансиверов в DUT.

  • Типы кабелей.

  • Длины кабелей.

  • Название и номер версии программ генерации трафика и DUT.

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

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

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

4.3. Единицы измерения

Рекомендуется применять для тестирования кабели (1) одного типа и длины, (2) произведенные (по возможности) одной компанией. Указанные в параграфе 4.1 параметры кабелей должны включаться в отчет вместе с результатами. В отчете необходимо указать, вычитались ли задержки в кабелях из приведенных в отчете значений. Должна указываться точность измерений генератора трафика (для современного тестового оборудования обычно около 20 нсек).

5. Скорость в линии

5.1. Определение

Синхронизация передачи или максимальная скорость передачи управляется «часами передачи» (transmit clock) в DUT. Синхронизация приема (максимальная скорость на входе) определяется синхронизацией передачи подключенного интерфейса.

Скорость в линии или скорость передачи кадров на физическом уровне — это максимальная «емкость» передачи в линию кадров заданного размера с частотой синхронизации передачи устройства DUT.

Термин «номинальная скорость в линии» (nominal value of line rate) определяет максимальную скорость передачи для данного порта — например, 1 GE, 10 GE, 40 GE, 100 GE (в Гбит/с — GE8).

Частота (скорость часов — clock rate) синхронизации передачи в любой паре соединенных интерфейсов никогда не будет в точности совпадать, следовательно требуется некий допуск. Этот допуск выражается значением PPM9. Стандарты IEEE опускают определенные отклонения частоты синхронизации передачи и сети Ethernet рассчитаны на наличие незначительных расхождений между часами соединенных интерфейсов. Это приводит к некоторым допускам линейной скорости трафика, генерируемого тестовым оборудованием для DUT.

Скорость в линии следует измерять числом кадров в секунду (FPS10).

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

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

Для допуска незначительных отклонений в скорости коммерчески доступных модулей синхронизации и других кварцевых генераторов стандарты Ethernet задают максимальные отклонения частоты синхронизации ±100 PPM от расчетного значения частоты. Следовательно, устройства DUT должны быть способны воспринимать кадры с отклонениями скорости ±100 PPM в соответствии со стандартами.

Очень мало устройств обеспечивает идеальную точность ±0,0 PPM в силу перечисленных ниже обстоятельств.

  1. Стандарты Ethernet разрешают отклонение частоты не более ±100 PPM с течением времени. Следовательно, для опорных генераторов будет нормальным незначительное изменение частоты с течением времени и при изменении температуры, а также в результате воздействия других факторов.

  2. Кристаллы кварца или модули часов обычно характеризуются некоторым отклонением, которое существенно меньше ±100 PPM. Зачастую эти вариации составляют не более ±30 PPM, чтобы устройство считалось «измерительным средством» (certification instrument).

При тестировании пропускной способности коммутаторов Ethernet на «скорости линии» любой конкретный коммутатор будет вносить свои вариации опорной частоты. Если тест выполняется с частотой +1 PPM по сравнению с частотой тестируемого коммутатора и тест происходит с установившейся скоростью линии, можно наблюдать постепенный рост задержки и, возможно, отбрасывание пакетов при переполнении буферов в коммутаторе. В зависимости от разницы вариаций частоты в двух соединенных устройствах можно заметить по истечении нескольких сотен микросекунд, нескольких миллисекунд или секунд с начала передачи трафика. Малую задержку и отсутствие потери пакетов можно продемонстрировать, установив для теста скорость чуть меньше чем при 100%-ой загрузке линии. Обычно загрузка в 99 % процентов показывает малую задержку и отсутствие потери пакетов. Ни в одном коммутаторе или маршрутизаторе Ethernet вы не увидите опорного генератора с отклонением опорной частоты в точности ±0,0 PPM. Очень мало (если есть) тестового оборудование обеспечивает точность ±0,0 PPM.

Производители тестового оборудования также осведомлены об этих стандартах и разрешают программно управляемый сдвиг (подстройку) опорной частоты в диапазоне ±100 PPM для компенсации вариаций частоты устройств DUT. Такая подстройка позволяет инженерам определить приблизительную скорость работы подключенного устройства и убедиться в том, что его параметры соответствуют требованиям стандартов.

5.3. Единицы измерения

«Скорость линии» (Line rate) измеряется числом кадров в единицу времени (frame rate):

   Frame Rate = Transmit-Clock-Frequency /
      (Frame-Length*8 + Minimum_Gap + Preamble + Start-Frame Delimiter)

Minimum_Gap представляет интервал между кадрами. Эта формула «масштабируется вверх и вниз» для скоростей 1 GE, 10 GE и т. д.

Пример для скорости 1 GE и кадров размером 64 байта приведен ниже.

      Frame Rate = 1000000000 / (64*8 + 96 + 56 + 8)
                 = 1000000000 / 672
                 = 1488095,2 FPS

С учетом допустимого отклонения ±100 PPM, коммутатор может «законно» передавать трафик со скоростью от 1487946,4 FPS до 1488244 FPS. Отклонение частоты на 1 PPM будет менять скорость на 1,488 FPS.

В реальной сети крайне маловероятно столкнуться с точной скоростью линии в течение очень короткого интервала времени. Различий в отбрасывании пакетов при скорости в 99% и 100% от скорости линии не наблюдается.

Скорость линии можно измерять при 100% с настройкой отклонения частоты -100 PPM.

Скорость линии следует измерять при 99,98% с отклонением 0 PPM.

Постройку PPM следует применять только при измерении скорости линии.

6. Буферизация

6.1. Буфер

6.1.1. Определение

Buffer Size — размер буфера

Термин «размер буфера» (buffer size) представляет общий объем памяти устройства DUT, служащей для буферизации кадров. Размер выражается в байтах (B), килобайтах (KB), мегабайтах (MB) или гигабайтах (GB). При указании размера буфера необходимо указывать также размер MTU (максимальный блок передачи) при тестировании, а также CoS (класс обслуживания) или DSCP (код дифференцированного обслуживания), поскольку распределение буферов зачастую определяется реализацией качества обслуживания. Дополнительную информацию можно найти в разделе 3 [RFC8239].

Пример. Значение Buffer Size устройства DUT при передаче кадров размером 1518 байтов составляет 18 MB.

Port Buffer Size — размер буфера в расчете на порт

Это размер в расчете на один порт для входного буфера, выходного буфера или относящейся к одному порту комбинации входного и выходного буфера. Отмечены три варианта размещения буферов, поскольку схема буферизации DUT может быть не известна или не проверена, поэтому информация о месте буферизации может прояснить архитектуру буферов и, следовательно, общий размер буфера. Значение Port Buffer Size является информационным и может предоставляться производителем DUT. Эти значения не тестируются при определении производительности, для оценки которой служит методология Maximum Port Buffer Size или Maximum Buffer Size.

Maximum Port Buffer Size — максимальный размер буфера на порту

Во многих случаях это совпадает с Port Buffer Size. В коммутаторах с архитектурой SoC11 имеется буфер порта и общая для всех портов буферная емкость. Maximum Port Buffer Size в контексте буферизации SoC представляет собой сумму размера буфера порта и максимального размера общего буфера, выделяемого для этого порта, и выражается в байтах (B), килобайтах (KB), мегабайтах (MB) или гигабайтах (GB). Значение Maximum Port Buffer Size требуется указывать вместе со значением MTU, использованным при измерении, и установленным для теста значением CoS или DSCP.

Пример. Тестирование DUT показало наличие буфера порта размером 3 KB для кадров размером 1518 байтов и общего буфера с максимальным размером 4,7 MB для кадров размером 1518 байтов и CoS = 0.

Maximum DUT Buffer Size — максимальный размер буфера в устройстве

Это общий размер буфера, который может иметь DUT. Скорей всего, он отличается от Maximum Port Buffer Size. Обычно он отличается и от суммы значений Maximum Port Buffer Size. Значение Maximum Buffer Size должно указываться вместе с использованным при измерении значением MTU, а также значением CoS или DSCP.

Пример. В DUT было определено наличие буфера порта размером 3 KB для кадров размером 1518 байтов и максимальный размер общего буфера 4,7 MB для кадров того же размера. Для этого DUT значение Maximum Buffer Size составляет 18 MB при MTU 1500 B и CoS = 0.

Burst — пик, всплеск

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

Microburst — микропик

Микропик представляет собой тип пика, для которого возникает отбрасывание пакетов при отсутствии установившейся или заметной перегрузки (насыщения) линии или устройства. Одной из характеристик микропика является отсутствие равномерного распределения в интервале T и интервалы меньше C (C — среднее время между двумя последовательными пакетами).

Intensity of Microburst — интенсивность микропика

Это процентное значение из диапазона 1 — 100% показывает уровень микропика. Чем больше значение, тем интенсивней микропик.

      I=[1-[ (Tp2-Tp1)+(Tp3-Tp2)+....(TpN-Tp(n-1) ] / Sum(packets)]]*100

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

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

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

6.1.3. Единицы измерения

При измерении буферов в DUT:

  • должен определяться размер буфера;

  • определяется размер буфера, который может быть предоставлен на каждом порту;

  • должен измеряться максимальный размер буфера порта;

  • должен измеряться максимальный размер буфера DUT;

  • при тестировании микропиков может быть указана их интенсивность;

  • следует указывать значение CoS или DSCP в процессе тестирования.

6.2. Инкаст

6.2.1. Определение

Термин Incast широко применяется в контексте ЦОД для обозначения картин трафика «многие в один» (many-to-one) или «многие во многие» (many-to-many). Как определено в этом параграфе инкаст является мерой числа входных и выходных портов, а также процента синхронизации между ними. Обычно в ЦОД это относится ко множеству разных входных портов сервера (many), передающих трафик в общий восходящий канал (many-to-one) или множество восходящих каналов (many-to-many). Эта картина обобщается для сети, как множество входящих портов, передающих трафик в один или несколько восходящих каналов.

Synchronous arrival time — синхронное прибытие

Когда два или более кадров размера L1 и L2 приходят на соответствующий входной порт или множество входных портов и время прибытия перекрывается для любого из битов кадров, кадры L1 и L2 называют прибывшими синхронно. Это называется инкастом, независимо от картины many-to-one (проще) или many-to-many.

Asynchronous arrival time — асинхронное прибытие

К этому типу относятся все случаи, когда не наблюдается «синхронного прибытия» кадров.

Percentage of synchronization — процент синхронизации

Это значение определяет степень перекрытия (число битов) между кадрами размеров L1, L2, .., Ln.

Пример. Два 64-байтовых кадра протяженностью L1 и L212 приходят на входные порты 1 и 2 устройства DUT. Имеется перекрытие времени прибытия кадров L1 и L2 на 6,4 байта. Следовательно, уровень синхронизации составляет 10%.

Stateful traffic — трафик с учетом состояния

Трафик пакетов, обмен которыми осуществляется по протоколу с поддержкой состояния соединения типа TCP.

Stateless traffic — трафик без учета состояния

Трафик пакетов, обмен которыми осуществляется по протоколу без поддержки состояния соединения типа UDP.

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

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

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

Синхронное прибытие нескольких кадров на устройство DUT рассматриваются, как формирование Incast.

6.2.3. Единицы измерения

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

Процент синхронизации должен быть ненулевым и должен быть указан.

7. Пропускная способность для приложений

7.1. Определение

В ЦОД сбалансированность сети определяется максимальной пропускной способностью при минимальных потерях. Это описывается параметром Goodput [TCP-INCAST], определяющим пропускную способность на прикладном уровне. Для стандартных приложений TCP очень малые потери могут оказывать значительное влияние на пропускную способность приложений. Определение Goodput представлено в [RFC2647], а применяемая здесь трактовка является вариантом этого определения.

Goodput выражается числом битов за единицу времени, пересылаемых на нужный выходной интерфейс DUT, за вычетом битов, переданных повторно.

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

При оценке пропускной способности ЦОД goodput представляет собой параметр, который следует измерять. Это дает реалистичное представление об использовании доступной пропускной способности. Одной из целей для ЦОД является максимизация goodput при минимизации потерь.

7.3. Единицы измерения

Goodput (G) определяется формулой:

      G = (S/F) * V

  • S представляет число байтов информации (payload) без учета заголовков пакетов и TCP;

  • F — размер кадров;

  • V скорость среды в байт/сек.

Пример. Передача файла по протоколу HTTP с использованием транспорта TCP в среде 10 Гбит/с.

Файл не может быть передан через среду Ethernet в форме одного непрерывного потока. Он должен разбиваться на множество кадров размером 1500 байтов при использовании стандартного значения MTU. Каждому пакету требуется 20 байтов для заголовка IP и 20 байтов для заголовка TCP, следовательно для передачи содержимого файла в пакете остается 1460 байтов. Системы на базе Linux вносят дополнительное ограничение до 1448 B, поскольку они дополнительно передают 12 байтов временной метки. Поскольку в этом примере данные передаются через сеть Ethernet к размеру пакета добавляется 26 байтов заголовка и результирующий кадр имеет размер 1526 байтов.

      G = 1460/1526 * 10 Гбит/с, что дает в результате 9,567 Гбит/с или 1,196 Гбайт/с.

Следует отметить, что в этом примере не учитывались дополнительные задержки Ethernet в виде мажкадрового интервала (не менее времени на передачу 96 битов), а также возможные конфликты (коллизии) в среде, влияние которых зависит от нагрузки.

При измерении Goodput следует документировать в дополнение в перечисленным в параграфе 4.1 данным также:

  • используемые стеки TCP;

  • версии OS;

  • Модель и номер версии микрокода сетевого адаптера (NIC).

Например, стеки TCP в Windows и разных версиях Linux могут влиять на результаты тестов на базе протокола TCP.

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

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

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

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

В тестируемых устройствах (DUT) не следует применять каких-либо возможностей специально для тестирования. Все влияния на безопасность сети, связанные с DUT, следует считать идентичными для тестовой и рабочей сети.

9. Взаимодействие с IANA

Этот документ не требует каких-либо действий со стороны IANA.

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

10.1. Нормативные документы

[RFC1242] Bradner, S., «Benchmarking Terminology for Network Interconnection Devices», RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2544] Bradner, S. and J. McQuaid, «Benchmarking Methodology for Network Interconnect Devices», RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.

[RFC5481] Morton, A. and B. Claise, «Packet Delay Variation Applicability Statement», RFC 5481, DOI 10.17487/RFC5481, March 2009, <https://www.rfc-editor.org/info/rfc5481>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8239] Avramov, L. and J. Rapp, «Data Center Benchmarking Methodology», RFC 8239, DOI 10.17487/RFC8239, August 2017, <https://www.rfc-editor.org/info/rfc8239>.

10.2. Дополнительная литература

[RFC2432] Dubray, K., «Terminology for IP Multicast Benchmarking», RFC 2432, DOI 10.17487/RFC2432, October 1998, <https://www.rfc-editor.org/info/rfc2432>.

[RFC2647] Newman, D., «Benchmarking Terminology for Firewall Performance», RFC 2647, DOI 10.17487/RFC2647, August 1999, <https://www.rfc-editor.org/info/rfc2647>.

[RFC2889] Mandeville, R. and J. Perser, «Benchmarking Methodology for LAN Switching Devices», RFC 2889, DOI 10.17487/RFC2889, August 2000, <https://www.rfc-editor.org/info/rfc2889>.

[RFC3918] Stopp, D. and B. Hickman, «Methodology for IP Multicast Benchmarking», RFC 3918, DOI 10.17487/RFC3918, October 2004, <https://www.rfc-editor.org/info/rfc3918>.

[TCP-INCAST] Chen, Y., Griffith, R., Zats, D., Joseph, A., and R. Katz, «Understanding TCP Incast and Its Implications for Big Data Workloads», April 2012, <http://yanpeichen.com/professional/usenixLoginIncastReady.pdf>.

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

Авторы благодарны Al Morton, Scott Bradner, Ian Cox и Tim Stevenson за рецензии и отклики.

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



Lucien Avramov


Google


1600 Amphitheatre Parkway


Mountain View, CA 94043


United States of America


Email: lucien.avramov@gmail.com


Jacob Rapp


VMware


3401 Hillview Ave.


Palo Alto, CA 94304


United States of America


Email: jhrapp@gmail.com


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


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


nmalykh@gmail.com 




1Internet Engineering Task Force.






2Internet Engineering Steering Group.






3Device Under Test.






4Packet Delay Variation — вариации задержки пакетов.






5Inter-Packet Delay Variation.






6Link Layer Discovery Protocol — протокол обнаружения канального уровня.






7Spanning Tree Protocol – протокол остовного дерева.






8Gigabit Ethernet.






9Parts Per Million — число долей на миллион.






10Frames per second.






11Switch on chip — однокристальный коммутатор (микросхема). Прим. перев.






12Так в оригинале. Прим. перев.



 							

	
			

									
						Рубрика: RFC, Измерения и тестирование					
					|
				
				
				Комментарии к записи RFC 8238 Data Center Benchmarking Terminology отключены

							

		


		
	

	
			

			
RFC 8239 Data Center Benchmarking Methodology


			

				Опубликовано 11.08.2017 автором Nikolai Malykh			


					

				
Internet Engineering Task Force (IETF)                        L. Avramov
Request for Comments: 8239                                        Google
Category: Informational                                          J. Rapp
ISSN: 2070-1721                                                   VMware
                                                             August 2017




Методология оценки производительности ЦОД


Data Center Benchmarking Methodology


PDF


Аннотация


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


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


Документ не является спецификацией стандарта (Internet Standards Track) и публикуется с информационными целями.


Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).


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


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


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


К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).


1. Введение


Картина трафика в ЦОД неоднородна и постоянно меняется. Это обусловлено характером и разнообразием применяемых в ЦОД приложений. Это могут быть большие потоки «запад-восток» («горизонтальные» потоки между серверами одного ЦОД) в одном центре и большие потоки «север-юг» («вертикальные» потоки из внешнего источника к серверу ЦОД) в другом, а также разные комбинации направлений потоков. Картины трафика по своей природе содержат пики (всплески) и включают потоки «многие к одному» «многие ко многим», «один ко многим». Потоки могут быть небольшими и чувствительными к задержками или большими и чувствительными к пропускной способности, а также включать смесь трафика UDP и TCP. Все перечисленное может существовать в одном кластере и поток может проходить через одно сетевое устройство. Тесты производительности сетевых устройств используются достаточно давно и описаны в [RFC1242], [RFC2432], [RFC2544], [RFC2889] и [RFC3918]. Эти тесты в основном привязаны к параметрам задержки и максимальной пропускной способности [RFC2889] тестируемого устройства (DUT3). Эти стандарты хороши для измерения теоретической максимальной пропускной способности, скорости пересылки и задержки в условиях теста, но не соответствуют реальным картинам трафика, который может проходить через сетевые устройства.


Ниже перечислены основные характеристики типичных сетевых устройств.


    

  • 

    Высокая плотность портов(не менее 48).
    

    • 

  • 

    Высокая скорость (вплоть до 100 Гбит/с на порт).
    

    • 

  • 

    Высокая пропускная способность (суммарная линейная скорость всех портов для уровня 2 и/или 3).
    

    • 

  • 

    Малые задержки (микросекунды или наносекунды).
    

    • 

  • 

    Незначительный объем буферов (мегабайты в объеме всего устройства).
    

    • 

  • 

    Пересылка на уровнях 2 и 3 (уровень 3 не обязателен).
    

    • 



В этом документе рассматривается методология оценки производительности физического сетевого оборудования (DUT) в составе ЦОД, включая сценарии с перегрузкой, анализ буферизации в коммутаторах, микропики, блокировку линий, а также разных ситуаций для смешанного трафика. В [RFC8238] приведены определения терминов, которые считаются нормативными для тестирования.


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


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


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


В разделах 2 — 6 этого документы используется деление на перечисленные ниже параграфы.


    

  • 

    Цели
    

    • 

  • 

    Методология
    

    • 

  • 

    Формат отчета
    

    • 



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


2. Тестирование скорости в линии


2.1. Цели


Целью этого метода является тестирование «максимальной скорости» (maximum rate) для пропускной способности, задержки и ее вариаций (jitter). Целями являются (1) выполнение теста (2) методология проверки способности DUT пересылать пакеты со скоростью среды при отсутствии насыщения.


2.2. Методология


Генератор трафика следует подключать ко все портам DUT. Должны выполняться два типа тестов: (1) тестирование пар портов [RFC2544] [RFC3918] и (2) тестирование с использованием полносвязной топологии (full-mesh) [RFC2889] [RFC3918].


Для всех тестов скорость передачи генератора трафика должна быть не более 99,98% от номинальной скорости линии (без дополнительной настройки PPM с учетом отклонений частоты на интерфейсах) для создания для устройства DUT «разумно жесткой» нагрузки (см. раздел 5 в [RFC8238]). Можно также представить результаты теста на меньшей скорости для лучшего понимания роста производительности в части задержек и их вариаций при скорости линии ниже 99,98%. Скорость поступления трафика следует измерять в процессе тестирования в процентах от скорости линии.


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


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


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


    

  • 

    Генератор трафика подключается к первому и последнему порту DUT.
    

    • 

  • 

    Порты попарно соединяются между собой в цепочку («змейку» — snake) — порт 2 с портом 3, порт 4 с портом 5 и т. д., порт N-2 с портом N-1, где N — общее число портов DUT.
    

    • 

  • 

    Порты 1 и 2 помещаются в одну VLAN X, порты 3 и 4 — в VLAN Y и т. д, порты N-1 и N — в одну VLAN Z.
    

    • 



Этот тест позволяет проверить скорость линии для уровней 2 и 3 [RFC2544] [RFC3918] в тех случаях, когда генератор трафика имеет лишь два порта. Задержки и их вариации в этом тесте не проверяются.


2.3. Формат отчета


Отчет должен включать перечисленные ниже сведения.


    

  • 

    Данные калибровки на физическом уровне в соответствии с разделом 4 [RFC8238].
    

    • 

  • 

    Число использованных портов.
    

    • 

  • 

    Скорость приема в процентах от пропускной способности при скорости передачи 99,98% от номинальной скорости линии на каждом порту для всех размеров пакетов от 64 до 9216 байтов. Рекомендуется увеличивать размер пакетов на 64 байта для каждой итерации, но приемлемы также размеры шага в 256 и 512 байтов. Чаще всего в отчетах указывают данные для пакетов размером 64, 128, 256, 512, 1024, 1518, 4096, 8000 и 9216 байтов.
    

    • 



Схему тестирования можно сформулировать с использованием [RFC6985].


    

  • 

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

    • 

  • 

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

    • 

  • 

    Значения задержки и ее вариаций указываются в единицах времени (обычно в миллисекундах или наносекундах) для пакетов размером от 64 до 9216 байтов.
    

    • 

  • 

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

    • 

  • 

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

    • 

  • 

    Тесты пропускное способности, задержки и ее вариаций можно проводить независимо с предоставлением в отчете надлежащей документации, однако следует проводить эти тексты одновременно.
    

    • 

  • 

    Методология предполагает наличие в устройстве DUT не менее 9 портов, поскольку для некоторых тестов нужны 9 и более портов.
    

    • 



3. Тестирование буферов


3.1. Цели


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


3.2. Методология


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


В описании представленных ниже процедур 1), 2), 3) и 4) используются «первая итерация», «вторая итерация» и «последняя итерация». Идея этого состоит в том, чтобы показать читателю логику изменений параметров теста в каждой итерации. Последняя итерация показывает финальное состояние переменных.


    

  1. 

    Максимальная эффективность буферизации.
    

    2. 



    

  • 

      

    • 

      Первая итерация. Входной порт 1 передает 64-байтовые пакеты со скоростью линии в выходной порт 2, а порт 3 передает небольшое известное количество избыточного (oversubscription) трафика (рекомендуется 1%) таких же пакетов (64 байта) в выходной порт 2. Размер буфера определяется произведением размера кадра на число кадров избыточного трафика в точке перегиба.
      

      • 

    • 

      Вторая итерация. Входной порт 1 передает 65-байтовые пакеты со скоростью линии в выходной порт 2, а порт 3 передает небольшое известное количество избыточного трафика (рекомендуется 1%) таких же пакетов (65 байтов) в выходной порт 2. Размер буфера определяется произведением размера кадра на число кадров избыточного трафика в точке перегиба.
      

      • 

    • 

      Последняя итерация. Входной порт 1 передает пакеты размеров B байтов со скоростью линии в выходной порт 2, а порт 3 передает небольшое известное количество избыточного трафика (рекомендуется 1%) таких же пакетов (B байтов) в выходной порт 2. Размер буфера определяется произведением размера кадра на число кадров избыточного трафика в точке перегиба.
      

      • 

    • 

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

      • 

    

    • 



    

  1. 

    Измерение максимального размера буфера порта.
    

    При фиксированном размере пакетов B как определено в процедуре 1) для фиксированного, принятого по умолчанию значения DSCP5/CoS6 = 0 и трафике с индивидуальной адресацией выполняются приведенные ниже процедуры.
    

    2. 



    

  • 

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

    • 

  • 

    Вторая итерация. Входной порт 2 передает со скоростью линии в выходной порт 3, тогда как порт 4 передает известное небольшое количество избыточного трафика (рекомендуется 1%) с таким же размером пакетов в выходной порт 3. Измеряется размер буфера путем умножения числа переданных избыточных кадров на размер кадра.
    

    • 

  • 

    Последняя итерация. Входной порт N-2 передает со скоростью линии в выходной порт N-1, тогда как порт N передает известное небольшое количество избыточного трафика (рекомендуется 1%) с таким же размером пакетов в выходной порт N-1. Измеряется размер буфера путем умножения числа переданных избыточных кадров на размер кадра.
    

    • 



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


    

  1. 

    Измерение максимальных размеров буферов пары портов.
    

    2. 



    

  • 

    Первая итерация. Входной порт 1 передает со скоростью линии в выходной порт 2, входной порт 3 — в выходной порт 4 и т. д. Входные порты N-1 и N будут давать избыточный трафик в размере 1% от скорости линии в выходные порты 2 и 3, соответственно. Значение размера буфера измеряется путем умножения числа переданных избыточных кадров на размер кадра для каждого выходного порта.
    

    • 

  • 

    Вторая итерация. Входной порт 1 передает со скоростью линии в выходной порт 2, входной порт 3 — в выходной порт 4 и т. д. Входные порты N-1 и N будут давать избыточный трафик в размере 1% от скорости линии в выходные порты 4 и 5, соответственно. Размер буфера измеряется путем умножения числа переданных избыточных кадров на размер кадра для каждого выходного порта.
    

    • 

  • 

    Последняя итерация. Входной порт 1 передает со скоростью линии в выходной порт 2, входной порт 3 — в выходной порт 4 и т. д. Входные порты N-1 и N будут давать избыточный трафик в размере 1% от скорости линии в выходные порты N-3 и N-2, соответственно. Значение размера буфера измеряется путем умножения числа переданных избыточных кадров на размер кадра для каждого выходного порта.
    

    • 



Эта серия тестов может повторяться с использованием разных значений DSCP/CoS, а также с использованием группового трафика.


    

  1. 

    Измеряется максимальный размер буфера DUT с портами «множество в один».
    

    2. 



    

  • 

    Первая итерация. Входные порты 1,2,… N-1 передают со скоростью [(1/[N-1])*99.98]+[1/[N-1]]% от скорости линии в выходной порт N.
    

    • 

  • 

    Вторая итерация. Входные порты 2,… N передают со скоростью [(1/[N-1])*99.98]+[1/[N-1]]% от скорости линии в выходной порт 1.
    

    • 

  • 

    Последняя итерация. Входные порты N,1,2…N-2 передают со скоростью [(1/[N-1])*99.98]+[1/[N-1]]% от скорости линии в выходной порт N-1.
    

    • 



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


Следует использовать индивидуальный, а затем групповой трафик для определения доли буфера при документированном выборе тестов. Также следует изменять значения CoS в пакетах для каждой итерации тестов, поскольку размер выделяемых буферов может зависеть от CoS. Рекомендуется менять входные и выходные порты случайным образом (документируя это) в разных тестах, чтобы измерить размер буфера на каждом порту DUT.


3.3. Формат отчета


Отчет должен включать указанную ниже информацию.


    

  • 

    Размер пакетов, при котором обеспечивалось наиболее эффективное использование буферов, вместе с DSCP/CoS.
    

    • 

  • 

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

    • 

  • 

    Максимальный размер буфера DUT.
    

    • 

  • 

    Размер использованных для теста пакетов.
    

    • 

  • 

    Размер «переподписки», если он отличался от 1%.
    

    • 

  • 

    Число входных и выходных портов и из расположение в DUT.
    

    • 

  • 

    Нужно указать повторяемость тестов — число итераций одного теста и процент отклонения между результатами в этих итерациях (максимум, минимум, среднее).
    

    • 



Процент отклонения — это показатель, определяющий разницу между измеренным и предыдущими значениями.


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


PV = ((x2-x1)/x1)*100, где x2 — минимальное значение задержки в текущем тесте, а x1 — в предыдущем.


Такая же формула применяется для отклонений максимального и среднего значения.


4. Тестирование микропиков трафика


4.1. Цели


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


Этот тест обеспечивает методологию, дополняющую тесты, которые описаны в [RFC1242], [RFC2432], [RFC2544], [RFC2889] и [RFC3918].


    

  • 

    Все пики следует передавать с интенсивностью 100% (определена в параграфе 6.1.1 [RFC8238]).
    

    • 

  • 

    Для этого теста должны использоваться все порты DUT.
    

    • 

  • 

    Рекомендуется тестировать все порты одновременно.
    

    • 



4.2. Методология


Генератор трафика должен быть подключен ко всем портам DUT. Для того, чтобы вызвать перегрузку в два (или более) входных порта должны передаваться пики пакетов, адресованные в один выходной порт. Простейшим вариантом является передача из двух входных портов в один выходной (2 в 1).


Пики должны передаваться с интенсивностью (определена в параграфе 6.1.1 [RFC8238]) 100%, означающей передачу пакетов в рамках пика с минимальными межпакетными интервалами. Число пакетов в пике подбирается методом проб и увеличивается, пока не начнутся потери пакетов. Агрегатное число пакетов от всех отправителей используется для расчета максимального числа микропиков, которое способно выдержать устройство DUT.


Рекомендуется менять входные и выходные порты в разных тестах для измерения максимальной «емкости» микропиков.


Интенсивность микропиков (см. параграф 6.1.1 в [RFC8238]) может меняться для получения максимальной «емкости» при разных входных скоростях.


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


Ниже приведен пример.


    

  • 

    Первая итерация. N-1 входных портов передают в один выходной порт.
    

    • 

  • 

    Вторая итерация. N-2 входных порта передают в два выходных порта.
    

    • 

  • 

    Последняя итерация. два входных порта передают в N-2 выходных порта.
    

    • 



4.3. Формат отчета


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


    

  • 

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

    • 

  • 

    Размер пакетов, использованных при тестировании.
    

    • 

  • 

    Число входных и выходных портов, а также их расположение в DUT.
    

    • 

  • 

    Требуется описать повторяемость тестов — число итераций одного теста и величину отклонений между итерациями (максимум, минимум, среднее).
    

    • 



5. «Пробки»


5.1. Цели


Блокировка HOLB8 или «пробка» — это влияющее на производительность явление, когда пакеты тормозятся первым пакетом, ожидающим пересылки в какой-то другой выходной порт. Определение этого феномена приведено в параграфе 5.5 RFC 2889 (Congestion Control). Этот раздел служит расширением RFC 2889 в контексте оценки производительности ЦОД.


Цель этого теста заключается в определении поведения DUT в случаях HOLB и измерение уровня потери пакетов.


Различия между этим тестом HOLB и RFC 2889 перечислены ниже.


    

  • 

    Тест HOLB начинают с 8 портов в двух группах по 4 порта в каждой вместо тестирования на 4 портах, как в параграфе 5.5 RFC 2889.
    

    • 

  • 

    Во второй итерации теста HOLB номера всех портов сдвигают на 1, это тоже отличается от теста HOLB в RFC 2889. Сдвиг портов продолжается до тех пор, пока каждый порт не побывает в роли первого в группе — это делается для того, чтобы учесть все отклонения в поведении SoC в устройстве DUT.
    

    • 

  • 

    Другим отличием является увеличение числа портов в тесте HOLB, чтобы трафик распределялся между четырьмя портами вместо двух (25% на каждый порт вместо 50%).
    

    • 

  • 

    В параграфе 5.3 приведены требования, дополняющие требования параграфа 5.5 в RFC 2889.
    

    • 



5.2. Методология


Для инициирования «пробки» в форме HOLB применяется группа из 4 портов, два из которых являются входными, два — выходными. На первом входном порту должны быть настроены два потока, каждый из которых имеет свой выходной порт. Второй входной порт будет перегружать второй выходной порт, передавая данные со скоростью линии. Цель заключается в проверке наличия потерь потока для первого выходного порта, на котором нет переподписки.


Генератор трафика должен подключаться по меньшей мере к 8 портам DUT и следует подключать его ко всем портам.


Отметим, что тесты, описанные в процедурах 1) и 2) этого параграфа имеют итерации, называемые первой, второй и последней. Идея состоит в том, чтобы показать первые две итерации для понимания читателем логики процесса. Последняя итерация показывает конечное состояние переменных.


    

  1. 

    Измерения для двух групп с 8 портами DUT.
    

    2. 



    

  • 

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

    Операции для первой группы портов описаны ниже.
    

    Входной порт 1 передает 50% трафика в выходной порт 3 и 50% — в выходной порт 4. Входной порт 2 передает со скоростью линии в выходной порт 4. Измеряются потери для трафика из входного порта 1 в выходной порт 3.
    

    Операции для второй группы портов описаны ниже.
    

    Входной порт 5 передает 50% трафика в выходной порт 7 и 50% — в выходной порт 8. Входной порт 6 передает со скоростью линии в выходной порт 8. Измеряются потери для трафика из входного порта 5 в выходной порт 7.
    

    • 

  • 

    Вторая итерация. Выполняется первая итерация со сдвигом всех портов на 1.
    

    Операции для первой группы портов описаны ниже.
    

    Входной порт 2 передает 50% трафика в выходной порт 4 и 50% — в выходной порт 5. Входной порт 3 передает со скоростью линии в выходной порт 5. Измеряются потери для трафика из входного порта 2 в выходной порт 4.
    

    Операции для второй группы портов описаны ниже.
    

    Входной порт 6 передает 50% трафика в выходной порт 8 и 50% — в выходной порт 9. Входной порт 7 передает со скоростью линии в выходной порт 9. Измеряются потери для трафика из входного порта 6 в выходной порт 8.
    

    • 

  • 

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

    Измеряются потери трафика из входного порта N в выходной порт 2 и из входного порта 4 ы выходной порт 6.
    

    • 



    

  1. 

    Измерения с N/4 групп для DUT с N портов.
    

    Трафик из входного порта расщепляется в 4 выходных порта (100/4 = 25%).
    

    2. 



    

  • 

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

    • 

  • 

    Вторая итерация. Номера портов в каждой группе смещаются на +1.
    

    • 

  • 

    Последняя итерация. Номера портов в каждой группе смещаются на N-1 и измеряются потери для каждой группы.
    

    • 



5.3. Формат отчета


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


    

  • 

    Конфигурация порта, включая число и расположение входных и выходных портов в DUT.
    

    • 

  • 

    Соответствие наблюдавшихся пробок описанию HOLB в разделе 5.
    

    • 

  • 

    Процент потерянного трафика.
    

    • 

  • 

    Требуется описать повторяемость тестов — число итераций одного теста и величину отклонений между итерациями (максимум, минимум, среднее).
    

    • 



6. Инкаст для трафика с учетом и без учета состояния


6.1. Цели


Целью этого теста является измерение значений TCP Goodput [TCP-INCAST] и задержки для комбинации больших и мелких потоков. Тест разработан для имитации смешанной среды потоков с учетом состояния (stateful flow), которым нужна высокая пропускная способность, и потоков без учета состояния, которые требуют малых задержек. Потоки с учетом состояния создаются путем генерации трафика TCP, а без учета состояния — путем генерации трафика UDP.


6.2. Методология


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


Один входной порт должен поддерживать через себя соединение TCP с получателем, подключенным к выходному порту. Трафик в потоке TCP должен передаваться с максимальной скоростью, поддерживаемой генератором трафика. Этот трафик TCP через DUT передается одновременно с трафиком без поддержки состояния, адресованным в тот же выходной порт. Трафик без поддержки состояния должен представлять собой микропик с интенсивностью 100%.


Рекомендуется менять входные и выходные порты в разных тестах, чтобы измерить максимальную «емкость» микропиков.


Интенсивность микропиков можно менять для получения «емкости» микропиков при разной входной скорости.


Рекомендуется использовать при тестировании все порты DUT.


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


Примеры


Вариации трафика с учетом состояний (TCP).


Для этого теста нужно генерировать трафик TCP. В итерациях теста число выходных портов можно менять.


    

  • 

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

    • 

  • 

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

    • 

  • 

    Последняя итерация. N-2 входных портов получают трафик TCP с учетом состояния и один входной порт получает трафик без учета состояния, который передается в один выходной порт.
    

    • 



Вариации трафика без учета состояний (UDP).


Для этого теста нужно генерировать трафик UDP. В итерациях теста число выходных портов можно менять.


    

  • 

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

    • 

  • 

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

    • 

  • 

    Последняя итерация. Один входной порт получает трафик TCP с учетом состояния и N-2 входных портов получают трафик без учета состояния, который передается в один выходной порт.
    

    • 



6.3. Формат отчета


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


    

  • 

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

    • 

  • 

    Полезная пропускная способность потока с учетом состояния.
    

    • 

  • 

    Задержка трафика без учета состояния.
    

    • 

  • 

    Требуется описать повторяемость тестов — число итераций одного теста и величину отклонений между итерациями (максимум, минимум, среднее).
    

    • 



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


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


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


Тесты производительности выполнялись по методу «черного ящика», когда все измерения проходят снаружи DUT.


В DUT не следует использовать при тестировании производительности нацеленные на это возможности. Любым влияния на безопасность сети со стороны DUT следует быть идентичными в тестовой и рабочей сети.


8. Взаимодействие с IANA


Этот документ не требует каких-либо действий со стороны IANA.


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


9.1. Нормативные документы


[RFC1242] Bradner, S., «Benchmarking Terminology for Network Interconnection Devices», RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.


[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.


[RFC2544] Bradner, S. and J. McQuaid, «Benchmarking Methodology for Network Interconnect Devices», RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.


[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.


[RFC8238] Avramov, L. and J. Rapp, «Data Center Benchmarking Terminology», RFC 8238, DOI 10.17487/RFC8238, August 2017, <https://www.rfc-editor.org/info/rfc8238>.


9.2. Дополнительная литература


[RFC2432] Dubray, K., «Terminology for IP Multicast Benchmarking», RFC 2432, DOI 10.17487/RFC2432, October 1998, <https://www.rfc-editor.org/info/rfc2432>.


[RFC2889] Mandeville, R. and J. Perser, «Benchmarking Metodology for LAN Switching Devices», RFC 2889, DOI 10.17487/RFC2889, August 2000, <https://www.rfc-editor.org/info/rfc2889>.


[RFC3918] Stopp, D. and B. Hickman, «Metodology for IP Multicast Benchmarking», RFC 3918, DOI 10.17487/RFC3918, October 2004, <https://www.rfc-editor.org/info/rfc3918>.


[RFC6985] Morton, A., «IMIX Genome: Specification of Variable Packet Sizes for Additional Testing», RFC 6985, DOI 10.17487/RFC6985, July 2013, <https://www.rfc-editor.org/info/rfc6985>.


[TCP-INCAST] Chen, Y., Griffith, R., Zats, D., Joseph, A., and R. Katz, «Understanding TCP Incast and Its Implications for Big Data Workloads», April 2012, <http://yanpeichen.com/professional/usenixLoginIncastReady.pdf>.


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


Авторы благодарят Al Morton и Scott Bradner за их рецензии и отклики.


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


Lucien Avramov


Google


1600 Amphitheatre Parkway


Mountain View, CA 94043


United States of America


Email: lucien.avramov@gmail.com


Jacob Rapp


VMware


3401 Hillview Ave.


Palo Alto, CA 94304


United States of America


Email: jhrapp@gmail.com




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


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


nmalykh@gmail.com 




1Internet Engineering Task Force.






2Internet Engineering Steering Group.






3Device Under Test.






4Switch-on-Chip — микросхема коммутации.






5Differentiated Services Code Point — код дифференцированного обслуживания.






6Class of Service — класс обслуживания.






7The percentage of variation.






8Head-of-line blocking.



 							

	
			

									
						Рубрика: RFC, Измерения и тестирование					
					|
				
				
				Комментарии к записи RFC 8239 Data Center Benchmarking Methodology отключены

							

		


		
	

	
			

			
RFC 8199 YANG Module Classification


			

				Опубликовано 31.07.2017 автором Nikolai Malykh			


					

				
Internet Engineering Task Force (IETF)                     D. Bogdanovic
Request for Comments: 8199                          Volta Networks, Inc.
Category: Informational                                        B. Claise
ISSN: 2070-1721                                                C. Moberg
                                                     Cisco Systems, Inc.
                                                               July 2017



YANG Module Classification


Классификация модулей YANG


PDF


Аннотация


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


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


В этом документе описан набор понятий и терминов для поддержки согласованной классификации модулей YANG.


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


Документ не относится к категории Internet Standards Track и публикуется с информационными целями.


Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.


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


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


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


К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).


1. Введение


IESG активно поощряет рабочие группы IETF к использования языка моделирования данных YANG [RFC7950] и протокола NETCONF4 [RFC6241] для целей управления конфигурацией (особенно в уставах новых рабочих групп [IESG-Statement]).


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


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


В этом документе представлен набор понятий и терминов для формирования таксономии согласованной классификации модулей YANG в двух аспектах:


    

  • 

    уровни модулей на основе абстракций;
    

    • 

  • 

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

    • 



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


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


Этот документ должен помочь трем категориям, указанным ниже.


    

  • 

    Во-первых, общая таксономия поможет в дискуссиях между SDO и отраслевыми консорциумами, цели которых определяются соответствующими областями работы.
    

    • 

  • 

    Во-вторых, операторы могут рассмотреть уровни абстракции модулей YANG, чтобы понять, какие модули YANG для сетевого сервиса и элементов сети доступны при организации сервиса. Сложно определить тип модуля без проверки самого модуля YANG. Имя модуля может включать полезную информацию, но не является определенным ответом. Например, модуль YANG L2VPN5 может быть модулем сетевого сервиса, готовым для использования сетевым оператором в качестве модели сервиса. Однако он может быть и модулем YANG для элемента сети, который содержит определения данных L2VPN, требуемые для настройки конфигурации отдельного устройства.
    

    • 

  • 

    В-третьих, такая таксономия поможет производителям оборудования (физического и виртуального), контроллеров и оркестраторов объяснить их заказчикам связи между различными модулями YANG, поддерживаемыми в их продукции.
    

    • 



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


Приведенные ниже термины определены в [RFC7950].


data model — модель данных


Модель данных описывает представление данных и доступ к ним.


module — модуль


Модуль YANG определяет иерархии узлов схемы. Со своими и импортированными или включенными из любого источника определениями модуль является самодостаточным и «компилируемым».


2. Уровни абстракции модулей YANG


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


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


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


    

  • 

    Модули элементов сети (Network Element YANG Module) описывают конфигурацию, данные состояния, операции и уведомления конкретных технологий или функций, связанных с устройством.
    

    • 

  • 

    Модули сетевого сервиса (Network Service YANG Module) описывают конфигурацию, данные состояния, операции и уведомления абстрактного представления сервиса, реализованного в одном или множестве элементов сети.
    

    • 



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


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


Например, опыт IETF показывает, что создание полезных модулей Network Element YANG (например, для протоколов маршрутизации или коммутации) требует команд, включающих разработчиков с опытом реализации таких протоколов.


                +--------------------------+
                |     Системы поддержки    |
                |     операция и бизнеса   |
                |         (OSS и BSS)      |
                +--------------------------+

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Модули YANG для сетевого сервиса

     +------------+      +-------------+      +-------------+
     |            |      |             |      |             |
     |  - L2VPN   |      |   - L2VPN   |      |    L3VPN    |
     |  - VPWS    |      |   - VPLS    |      |             |
     |            |      |             |      |             |
     +------------+      +-------------+      +-------------+

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Модули YANG для элементов сети

+------------+  +------------+  +-------------+  +------------+
|            |  |            |  |             |  |            |
|    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |
|            |  |            |  |             |  |            |
+------------+  +------------+  +-------------+  +------------+

  L2VPN - виртуальная частная сеть L2
  L3VPN - виртуальная частная сеть L3
  VPWS - виртуальный частный провод
  VPLS - виртуальная частная ЛВС


Рисунок 1. Абстрактные уровни модулей YANG.



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


2.1. Модули YANG для сетевого сервиса


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


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


YANG позволяет использовать разные шаблоны для описания сетевого сервиса — от монолитных до компонентных.


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


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


Например, сервис L2VPN может быть организован на основе множества технологий транспортных сетей, включая MPLS и Carrier Ethernet. Компонентный подход позволит применять определения интерфейсов между пользователем и сетью (UNI9), такие как MEF UNI или MPLS, независимо от базовой транспортной сети. При монолитном подходе нужно будет разрабатывать модули для конкретной комбинации транспорта и определений интерфейсов.


Пример модуля Network Service YANG содержится в [RFC8049], где представлена абстрактная модель конфигурации сервиса L3 IP VPN. Этот модуль включает концепцию доступа сайта в сеть (site-network-access) для представления параметров физического соединения. Оркестратор принимает операции над экземплярами сервиса в соответствии с модулем сервиса и разбирает данные в параметры конфигурации в соответствии с модулями Network Element YANG для настройки участвующих в сервисе элементов сети. В случае L3VPN параметры site-network-access будут транслироваться в параметры модулей Network Element YANG для соответствующих элементов.


2.2. Модули YANG для элементов сети


Модули Network Element YANG описывают характеристики сетевых устройств в соответствии с определениями производителей этих устройств. Модули обычно структурированы по функциям устройства. Например, конфигурация интерфейсов [RFC7223], конфигурация OSPF [OSPF-YANG], конфигурация ACL10 [ACL-YANG].


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


3. Происхождение модуля YANG


Документ предлагает классифицировать модули YANG по типу их происхождения — стандартные (Standard) модули, фирменные (Vendor-Specific) модули и расширения, пользовательские (User-Specific) модули и расширения.


Предложенная классификация применима как для модулей Network Element YANG так и для Network Service YANG.


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


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


+----------------+
|Пользовательские|
|   расширения   |
+-------+--------+
    Дополнения
+-------+--------+  +----------------+  +----------------+
|   Фирменные    |  |Пользовательские|  |Пользовательские|
|   расширения   |  |   расширения   |  |   расширения   |
+-------+--------+  +-------+--------+  +-------+--------+
   Дополнения         Дополнения          Дополнения
+-------+-------------------+--------+  +-------+--------+  +----------------+
|            Стандартные             |  |   Фирменные    |  |Пользовательские|
|              модули                |  |     модули     |  |     модули     |
+------------------------------------+  +----------------+  +----------------+


Рисунок 2. Варианты происхождения модулей YANG.


3.1. Стандартные модули YANG


Стандартные модули YANG публикуют организации SDO. Многие SDO создают спецификации в соответствии с формальным процессом для создания стандартов, которые будут полезны их потребителям.


Жизненные циклы таких модулей определяются циклами стандартизации и не привязаны к конкретной реализации.


Примерами SDO в сетевой отрасли могут служить IETF и IEEE.


3.2. Фирменные модули YANG и расширения


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


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


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


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


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


3.3. Пользовательские модули YANG и расширения


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


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


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


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


Документ не связан с какими-либо вопросами безопасности.


5. Взаимодействие с IANA


Этот документ не требует действий со стороны IANA.


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


6.1. Нормативные документы


[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.


[RFC7223] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 7223, DOI 10.17487/RFC7223, May 2014, <http://www.rfc-editor.org/info/rfc7223>.


[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <http://www.rfc-editor.org/info/rfc7950>.


[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, «YANG Data Model for L3VPN Service Delivery», RFC 8049, DOI 10.17487/RFC8049, February 2017, <http://www.rfc-editor.org/info/rfc8049>.


6.2. Дополнительная литература


[ACL-YANG] Bogdanovic, D., Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, «Network Access Control List (ACL) YANG Data Model», Work in Progress, draft-ietf-netmod-acl-model-11, June 2017.


[IESG-Statement] «Writable MIB Module IESG Statement», <https://www.ietf.org/iesg/statement/writable-mib-module.html>.


[OSPF-YANG] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, «Yang Data Model for OSPF Protocol», Work in Progress, draft-ietf-ospf-yang-08, July 2017.


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


Спасибо David Ball и Jonathan Hansford за отклики и предложения.


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


Dean Bogdanovic


Volta Networks, Inc.


Email: dean@voltanet.io


Benoit Claise


Cisco Systems, Inc.


De Kleetlaan 6a b1


1831 Diegem


Belgium


Phone: +32 2 704 5622


Email: bclaise@cisco.com


Carl Moberg


Cisco Systems, Inc.


Email: camoberg@cisco.com


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


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


nmalykh@protokols.ru 




1Standards development organization.






2Internet Engineering Task Force.






3Internet Engineering Steering Group.






4Network Configuration Protocol — протокол настройки конфигурации сети.






5Layer 2 Virtual Private Network — виртуальная частная сеть L2.






6Operations Support System — система поддержки операций.






7Business Support System — система поддержки бизнеса.






8VPN Routing and Forwarding — маршрутизация и пересылка VPN.






9User-Network Interface.






10Access control list — список управления доступом.



 							

	
			

									
						Рубрика: RFC					
					|
				
				
				Комментарии к записи RFC 8199 YANG Module Classification отключены

							

		


		
	

	
			

			
RFC 8201 Path MTU Discovery for IP version 6


			

				Опубликовано 28.07.2017 автором Nikolai Malykh			


					

				
Internet Engineering Task Force (IETF)                         J. McCann
Request for Comments: 8201                 Digital Equipment Corporation
STD: 87                                                       S. Deering
Obsoletes: 1981                                                  Retired
Category: Standards Track                                       J. Mogul
ISSN: 2070-1721                            Digital Equipment Corporation
                                                          R. Hinden, Ed.
                                                    Check Point Software
                                                               July 2017



Path MTU Discovery for IP version 6


Обнаружение MTU на пути для IPv6.


PDF


Аннотация


Этот документ описывает определение MTU1 для пути (Path MTU Discovery или PMTUD) для протокола IP версии 6. Механизм по большей части создан на основе RFC 1191, определяющего Path MTU Discovery для IP версии 4. Документ отменяет RFC 1981.


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


Документ относится к категории Internet Standards Track.


Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.


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


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


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


К документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).


Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права, этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards, за исключением форматирования документа для публикации или перевода с английского языка на другие языки.


1. Введение


Когда узел IPv6 имеет большой объем данных для передачи другому узлу, эти данные передаются в серии пакетов IPv6, размер которых не превышает Path MTU (PMTU). Другим вариантом является фрагментация большого пакета в серию фрагментов, размер которых не превышает PMTU.


Обычно предпочтительно использовать для пакетов наибольший размер, поддерживаемый на пути между источником и получателем без необходимости фрагментации IPv6. Такой размер называется Path MTU и он равен минимальному значению MTU среди всех каналов, образующих путь. Этот документ задаёт стандартный механизм для определения PMTU на произвольном пути.


Узлам IPv6 следует реализовать Path MTU Discovery чтобы обнаруживать и использовать пути с PMTU больше минимального размера IPv6 MTU [RFC8200]. Минимальная реализация IPv6 (например, ПЗУ загрузки) может отказаться от реализации Path MTU Discovery. Узлы, не реализующие Path MTU Discovery должны использовать минимальное значение IPv6 MTU, заданное в [RFC8200], как максимальный размер пакета. В многих случаях это ведёт к использованию пакетов размером меньше возможного, поскольку на многих путях PMTU превышает минимальное значение IPv6 MTU. Узел, передающий пакеты размером существенно меньше Path MTU, потребляет избыточные ресурсы сети и может иметь неоптимальную пропускную способность.


Реализующие Path MTU Discovery узлы, передающие пакеты размером больше минимального IPv6 MTU, могут сталкиваться с проблемами связности, если сообщения ICMPv6 [ICMPv6] не передаются или блокируются. Например, это может приводить к тому, что соединение TCP после корректного трехэтапного согласования «зависает» при передаче данных. Такое состояние называют «чёрной дырой» (black-hole connection) [RFC2923]. Механизм Path MTU Discovery полагается при определении MTU для пути на сообщения ICMPv6 PTB.


Определённое в этом документе расширение для Path MTU Discovery описано в [RFC4821]. RFC 4821 определяет механизм для уровня пакетирования (Packetization Layer Path MTU Discovery или PLPMTUD), предназначенный для использования на путях, где доставка хосту сообщений ICMPv6 не гарантируется.


Примечание. Этот документ обновляет [RFC1981], опубликованный до [RFC2119]. Хотя в RFC 1981 применяется стиль написания требований «следует/должно» с выделением шрифтом, в этом документе не применяются соглашения RFC 2119 по такому выделению.


2. Термины


node — узел 


Устройство, реализующее IPv6.


router — маршрутизатор 


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


host — хост


Любой узел, не являющийся маршрутизатором.


upper layer — вышележащий уровень


Протокольный уровень, расположенный непосредственно над IPv6. Примерами являются транспортные протоколы TCP и UDP, протоколы управления типа ICMP, протоколы маршрутизации, такие как OSPF, а также протоколы, «туннелируемые» через IPv6 (т. е., инкапсулированные в пакеты IPv6), такие как IPX (Internetwork Packet Exchange — пакет межсетевого обмена), AppleTalk или IPv6.


link — канал


Коммуникационный объект или среда, посредством которых узлы могут взаимодействовать на канальном уровне (уровне, расположенном непосредственно под IPv6). Примерами могут служить сети Ethernet (с мостами или без них), каналы PPP, сети X.25, Frame Relay или ATM, а также туннели сетевого или вышележащих уровней (например, IPv4 или IPv6).


interface — интерфейс


Подключение узла к каналу.


address — адрес 


Идентификатор уровня IPv6 для интерфейса или группы интерфейсов.


packet — пакет 


Заголовок IPv6 и данные (payload). Пакет может иметь размер не больше PMTU, а при большем размер он фрагментируется на серию пакетов (фрагментов), размером не более PMTU.


link MTU — MTU для канала


Максимальный передаваемый блок (максимальное число октетов в пакете, который можно передать по каналу).


path — путь


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


path MTU — MTU для пути


Минимальное значение среди MTU каналов на пути между узлом-источником и получателем.


PMTU


MTU для пути.


Path MTU Discovery — определение MTU для пути


Процесс определения PMTU для пути.


EMTU_S


Эффективное значение MTU для передачи. Используется протоколами вышележащего уровня для ограничения размера пакетов IP, помещаемых в очередь на передачу [RFC6691] [RFC1122].


EMTU_R


Эффективное значение MTU для приёма, т. е. наибольший размер пакета, который может собрать получатель [RFC1122].


flow — поток


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


flow id — идентификатор потока


Комбинация адреса источника и отличной от 0 метки потока.


3. Обзор протокола


Этот документ описывает метод динамического определения PMTU для пути. Основная идея состоит в том, что узел-источник изначально считает значением PMTU величину (известную) MTU первого этапа пути (first hop). Если какой-либо из переданных пакетов оказывается слишком велик для пересылки тем или иным узлом на пути, этот узел отбросит пакет и передаст источнику сообщение ICMPv6 Packet Too Big (PTB). При получении такого сообщения источник снижает предполагаемое значение PMTU для пути в соответствии с MTU столкнувшегося с проблемой пересылки узла, указанному в сообщении PTB. Снижение PMTU заставляет источник передавать пакеты меньшего размера или менять значение EMTU_S, чтобы заставить вышележащий уровень снизить размер передаваемых пакетов IP.


Процесс Path MTU Discovery завершается, когда оценка узлом-источником значения PMTU не превышает фактическое значение PMTU. Отметим, что до завершения этого процесса может произойти несколько итераций «передан пакет — получено сообщение PTB», поскольку на дальнейшем пути может оказаться несколько узлов с меньшими MTU. Узел может прервать процесс определения, перейдя к передаче пакетов с минимальным значением IPv6 MTU.


PMTU для пути может меняться с течением времени в результате изменения топологии маршрутов. Снижение PMTU обнаруживается получением сообщений PTB. Для обнаружения роста PMTU на пути узел периодически повышает предполагаемое значение PMTU. Это почти всегда ведёт к отбрасыванию пакетов и получению сообщений PTB, поскольку в большинстве случаев PMTU на пути не меняется. Поэтому попытки обнаружить рост PMTU на пути следует предпринимать нечасто.


Path MTU Discovery может работать как для индивидуальных, так и для групповых адресатов. В случае группового получателя пакеты к разным узлам группы могут идти по разным путям. Каждый из путей может иметь своё значение PMTU и один групповой пакет может вызывать множество сообщений, каждое из которых указывает своё значение next-hop MTU. Минимальное значение PMTU из числа полученных определяет размер последующих пакетов для этого группового адресата.


Отметим, что механизм Path MTU Discovery должен применяться даже в тех случаях, когда узел считает, что адресат подключён к тому же каналу, поскольку адресат может иметь значение PMTU меньше чем MTU для канала. В ситуации когда соседний маршрутизатор служит прокси-ND [ND] для того или иного получателя, адресат может казаться подключённым напрямую, а фактически быть отделен несколькими маршрутизаторами.


4. Требования к протоколу


Как отмечено в разделе 1, от узлов IPv6 не требуется реализация Path MTU Discovery и требования этого раздела относятся лишь к реализациям, поддерживающим Path MTU Discovery.


Узлам следует должным образом проверять содержимое (payload) сообщения ICMPv6 PTB для уверенности в том, что оно служат ответом на переданный ранее трафик (т. е. сообщает об ошибке, связанной с пакетом IPv6, действительно переданным приложением) в соответствии с [ICMPv6].


При получении узлом сообщения PTB, указывающего next-hop MTU меньше минимального IPv6 MTU, узел должен отбросить сообщение. Узлам недопустимо снижать оценку Path MTU до значения меньше минимального IPv6 MTU в ответ на получение сообщения PTB.


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


После приёма сообщения PTB узел должен попытаться избежать получения таких сообщений в ближайшем будущем, уменьшая размер пакетов, передаваемых по этому пути. Использование PMTU, превышающих минимальное значение IPv6 MTU, может вызвать сообщения PTB. Поскольку на такие сообщения (и отбрасывание вызвавших их пакетов) тратятся ресурсы сети, использующие Path MTU Discovery узлы должны снижать PMTU как можно быстрее.


Узлы могут обнаруживать рост PMTU, но для этого нужно передавать пакеты размером больше текущей оценки PMTU, а вероятность роста PMTU невелика, поэтому такие попытки должны быть нечастыми. Попытки обнаружить рост PMTU (путём передачи пакета размером больше текущего значения) недопустимо предпринимать раньше чем через 5 минут после приёма сообщения PTB для данного пути. Рекомендуется устанавливать для таймера удвоенное минимальное значение (10 минут).


Узлу недопустимо увеличивать оценку Path MTU в ответ на сообщение PTB, поскольку сообщение со значением Path MTU выше текущей оценки может оказаться устаревшим пакетом, «застрявшим» в сети, ложным пакетом, связанным с DoS4-атакой), или следствием наличия нескольких путей к адресату (с разными PMTU).


5. Вопросы реализации


В этом разделе рассмотрены вопросы, связанные с реализацией Path MTU Discovery. Это не спецификация, а просто замечания в помощь разработчикам. Рассматривается несколько вопросов:


    

  • 

    на каких уровнях реализуется Path MTU Discovery;
    

    • 

  • 

    как кэшируются данные PMTU;
    

    • 

  • 

    как удаляются устаревшие сведения PMTU;
    

    • 

  • 

    что делает транспортный уровень и уровни над ним?
    

    • 



5.1. Уровни


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


Реализация Path MTU Discovery на уровне пакетирования упрощает некоторые проблемы взаимодействия уровней, но имеет ряд недостатков — может потребоваться переработка реализации для каждого протокола пакетирования, сложно обмениваться данными PMTU между разными уровнями пакетирования, а ориентированным на соединения состояниям в некоторых уровнях пакетирования может быть сложно поддерживать сведения PMTU достаточно долго. Поэтому предлагается хранить сведения PMTU на уровне IP, а уровню ICMPv6 — обрабатывать сообщения PTB. Уровни пакетирования могут реагировать на изменение PMTU сменой размера передаваемых сообщений. Для поддержки этих уровней для уровня пакетирования может потребоваться способ узнавать у смене значения MMS_S (максимальный размер передаваемого транспортного сообщения [RFC1122]).


MMS_S — это размер транспортного сообщения, рассчитываемый вычитанием размера заголовка IPv6 (включая заголовки расширения IPv6) из максимального размера пакета IP, который можно передать (EMTU_S). Значение MMS_S ограничено рядом факторов, включая PMTU, поддержку фрагментации и сборки пакетов, ограничения сборки пакетов (см. параграф 4.5 в [RFC8200]). Когда источник может обеспечивать фрагментацию, для EMTU_S устанавливается значение EMTU_R, указанное получателем с использованием протокола вышележащего уровня или на основе требований протокола (1500 октетов для IPv6). При передаче сообщения размером больше PMTU отправитель создаёт фрагменты, размер которых ограничен значением PMTU. Если фрагментация у отправителя нежелательна, для EMTU_S устанавливается значение PMTU и предполагается, что вышележащий протокол сам выполнит фрагментацию (и сборку) или иным способом ограничит размер сообщения.


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


5.2. Сохранение сведений PMTU


В идеальном случае значение PMTU следует связывать с конкретным путём, по которому пакеты проходят между отправителем и получателем. Однако в большинстве случаев узел не имеет сведений для полного и точного определения такого пути. Скорее узел должен связывать PMTU с неким локальным представлениям пути, выбор которого остаётся за реализацией. На узлах с несколькими интерфейсами данные Path MTU следует поддерживать для каждого канала IPv6. В случае группового получателя пакеты могут идти по разным путям т локальное представления должно отражать как можно более широкий набор путей.


Реализация может поддерживать по меньшей мере 1 значение PMTU для всех передаваемых узлом пакетов, используя для этого минимальное среди известных узлу значений PMTU. Такой подход вероятно приведёт к передаче по многим путям пакетов с размером меньше возможного. В случае маршрутизации по нескольким путям (например, Equal-Cost Multipath Routing — ECMP) между источником и получателем может существовать множество путей.


Реализация может применять в качестве локального представления пути адрес получателя. Значение PMTU, связанное с получателем, будет минимальным из PMTU для всех известных путей к этому адресату. Этот подход обеспечивает оптимальный размер пакетов для каждого адресата5 и хорошо интегрируется с концептуальной моделью хоста, описанной в [ND] — значение PMTU может храниться в соответствующей записи кэша адресатов.


Если применяются потоки [RFC8200], реализация может использовать flow id в качестве локального представления пути. Пакеты для одного адресата, относящиеся к разным потокам, могут использовать разные пути, как в случае ECMP с выбором пути на основе flow id. Такой подход может обеспечить оптимальный размер пакетов для каждого потока, обеспечивая более тонкую детализацию, чем поддержка PMTU по адресатам. Для пакетов с заданной источником маршрутизацией (пакеты с заголовком IPv6 Routing [RFC8200]) локальное представления пути может задавать source-route.


Исходно PMTU для пути предполагается равным (известному) значению MTU для первого канала на пути (first-hop).


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


Примечание. Если исходный пакет включал заголовок Routing, этот заголовок следует использовать для определения местоположения адреса получателя в исходном пакете. Если Segments Left = 0, адресом получателя будет поле Destination Address в заголовке IPv6, в ином случае — последний адрес (Address[n]) в заголовке Routing.


Затем узел использует в качестве предварительного значения PMTU большее из значений поля MTU в сообщении PTB и минимального IPv6 MTU и сравнивает предварительное значение PMTU с имеющимся. Если предварительное значение PMTU меньше, оно заменяет собой имеющееся значение PMTU для пути.


Уровни пакетирования должны уведомляться о снижении PMTU. Любой экземпляр уровня пакетирования (например, соединение TCP), активно использующий путь, информируется о снижении оценки PMTU.


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


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


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


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


5.3. Отбрасывание устаревших сведений PMTU


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


Если устаревшее значение PMTU слишком велико, это будет обнаружено почти сразу после отправки достаточно большого пакета по этому пути. Для обнаружения слишком малых устаревших значений PMTU какого-либо механизма нет, поэтому реализации следует поддерживать «старение» кэшированных записей. Когда значение PMTU не снижается слишком долго (порядка 10 минут), следует проверить возможность применения большего значения PMTU.


Примечание. Реализации следует предоставлять возможность изменения времени ожидания, включая установку «бесконечного» значения. Например, узлы подключённые по каналу с большим MTU к устройству, соединённому с Internet каналом с меньшим MTU, никогда не увидят новых нелокальных значений PMTU, поэтому им не следует предпринимать попыток такого обнаружения.


5.4. Действия уровня пакетирования


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


Реализация TCP должна сохранять также максимальный размер сегмента (Maximum Segment Size или MSS), полученный от партнёра, который представляет EMTU_R (наибольший пакет, который может быть собран получателем), и ей недопустимо передавать сегменты больше этого MSS, независимо от PMTU. Значение, передаваемое в опции TCP MSS, не зависит от PMTU и определяется ограничением сборки у получателя (EMTU_R). Значение опции MSS используется другой стороной соединения, которая может иметь своё значение PMTU. Информация о выборе опции TCP MSS приведена в разделе 5 и параграфе 8.3 [RFC8200].


Приём сообщения PTB говорит об отбрасывании пакета узлом, передавшим это сообщение ICMPv6. Протокол вышележащего уровня с гарантией доставки будет обнаруживать такие потеря и восстанавливать данные с помощью механизмов повтора передачи. Повтор может приводить к задержкам в зависимости от используемого вышележащим протоколом метода обнаружения потерь. Если процесс Path MTU Discovery требует нескольких шагов для определения PMTU на всем пути, это может в конечном итоге задержать повтор передачи на много интервалов кругового обхода. Как вариант, повтор передачи может происходить сразу при уведомлении о снижении Path MTU, но лишь для конкретного соединения, указанного в сообщении PTB. При повторе следует использовать размер пакета не больше нового значения PMTU.


Примечание. Уровень пакетирования, обнаруживший потерю пробного пакета, должен изменить размер сегмента при повторе передачи. Однако применения значения из последнего сообщения PTB может привести к дополнительным потерям, обусловленных меньшими PMTU на последующих маршрутизаторах пути. Это приведёт к потере всех повторных сегментов и вызовет ненужную перегрузку а также передачу дополнительных пакетов, когда какой-либо маршрутизатор объявит меньшее значение MTU. Поэтому уровень пакетирования, использующий повтор передачи, отвечает также за контроль перегрузок при повторах [RFC8085].


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


5.5. Проблемы других транспортных протоколов


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


Path MTU Discovery для IPv4 [RFC1191] использует NFS в качестве примера приложения на основе UDP, получающего преимущества от обнаружения PMTU. Позднее в [RFC7530] было указано, что поддерживаемый между NFS и IP транспортный уровень должен применять стандартизованный IETF транспортный протокол, в котором указано предотвращение перегрузки в сети. В качестве такого транспорта применяются TCP, Stream Control Transmission Protocol (SCTP) [RFC4960] и Datagram Congestion Control Protocol (DCCP) [RFC4340], которые отвечают за соответствие передаваемых сегментов (кроме зондов) значению Path MTU и поддержку зондов PMTU Discovery при необходимости.


5.6. Интерфейс управления


Предполагается, что реализация позволяет системным утилитам:


    

  • 

    отключать Path MTU Discovery для указанного пути;
    

    • 

  • 

    менять значение PMTU, связанное с заданным путём.
    

    • 



Первый вариант можно реализовать с помощью флага, связанного с путём, при установке которого уровень IP не передаёт в соответствующий канал пакеты размером больше минимального IPv6 MTU. Эти возможности можно применить для обработки аномалий или при неспособности протокола маршрутизации получить значения Path MTU.


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


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


Этот механизм Path MTU Discovery открывает возможность для двух DoS-атак на основе ложных сообщений PTB.


В первом варианте ложные сообщения указывают слишком малые значения PMTU. Узлу-жертве никогда не следует устанавливать PMTU меньше минимального IPv6 MTU. Снижение PMTU в результате атаки ведёт к неоптимальной производительности.


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


Обе эти атаки могут создавать «чёрные дыры» в соединениях, когда трехэтапное согласование TCP проходит нормально, а последующая передача данных «зависает».


Злоумышленник также может вызвать проблемы, заблокировав получение жертвой сообщений PTB, но для этого есть более простые DoS-атаки.


Если фильтрация ICMPv6 препятствует получению сообщений ICMPv6 PTB, источник не сможет узнать фактическое значение MTU для пути. В документе «Packetization Layer Path MTU Discovery» [RFC4821] предложен механизм, не использующий сообщения ICMPv6 и обеспечивающий более высокую отказоустойчивость по сравнению со стандартным PMTUD. Он не подвержен возникновению «чёрных дыр» из-за фильтрации сообщений ICMPv6 (см. рекомендации по такой фильтрации в [RFC4890].


7. Взаимодействие с IANA


Этот документ не требует действий IANA.


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


8.1. Нормативные документы


[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.


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


8.2. Дополнительная литература


[FRAG] Kent, C. and J. Mogul, «Fragmentation Considered Harmful», In Proc. SIGCOMM ’87 Workshop on Frontiers in Computer Communications Technology, DOI 10.1145/55483.55524, August 1987.


[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.


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


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


[RFC1981] McCann, J., Deering, S., and J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.


[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.


[RFC2923] Lahey, K., «TCP Problems with Path MTU Discovery», RFC 2923, DOI 10.17487/RFC2923, September 2000, <http://www.rfc-editor.org/info/rfc2923>.


[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.


[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.


[RFC4890] Davies, E. and J. Mohacsi, «Recommendations for Filtering ICMPv6 Messages in Firewalls», RFC 4890, DOI 10.17487/RFC4890, May 2007, <http://www.rfc-editor.org/info/rfc4890>.


[RFC4960] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.


[RFC6691] Borman, D., «TCP Options and Maximum Segment Size (MSS)», RFC 6691, DOI 10.17487/RFC6691, July 2012, <http://www.rfc-editor.org/info/rfc6691>.


[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., «Network File System (NFS) Version 4 Protocol», RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.


[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, «UDP Usage Guidelines», BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>. 


Приложение A. Сравнение с RFC 1191


RFC 1981 (отменен этим документом) был основан по большей части на RFC 1191, описывавшем Path MTU Discovery для IPv4. Некоторые части RFC 1191 не были использованы в RFC 1981:


router specification — спецификация маршрутизатора 


Сообщения PTB и соответствующее поведение маршрутизаторов описаны в [ICMPv6].


Don’t Fragment bit — флаг запрета фрагментирования.


Флаг DF не применяется в пакетах IPv6.


TCP MSS discussion — обсуждение TCP MSS


Выбор значения для передачи в опции TCP MSS рассматривается в [RFC8200].


old-style messages — сообщения старого стиля


Все сообщения PTB указывают MTU связанного с ошибкой канала.


MTU plateau tables — таблицы плато MTU


Не нужны, поскольку сообщения старого стиля не применяются.


Приложение B. Отличия от RFC 1981


Этот документ основан на RFC 1981, но отличается от него, как указано ниже.


    

  • 

    В разделе 1. Введение поясняется, что целью PMTUD является снижение фрагментации IPv6.
    

    • 

  • 

    В раздел 1. Введение добавлен текст о влиянии на PMTUD блокировки сообщений ICMPv6.
    

    • 

  • 

    В раздел 1. Введение добавлено примечание о том, что данный документ не следует RFC 2119 и указывает уровни требований «должен/следует» строчными буквами.
    

    • 

  • 

    В раздел 1. Введение добавлена краткая информация о PLPMTUD и ссылка на RFC 4821.
    

    • 

  • 

    Исправлен текст раздела 2. Термины в соответствии с современной терминологией уровня пакетирования.
    

    • 

  • 

    В раздел 4. Требования к протоколу добавлено пояснение о том, что узлам следует проверять содержимое сообщения ICMP PTB в соответствии с RFC 4443, а также обрабатывать снижение PMTU как можно быстрее.
    

    • 

  • 

    Из раздела 4. Требования к протоколу исключён текст о сообщении PTB, указывающем next-hop MTU меньше минимального IPv6 MTU, поскольку это исключено из [RFC8200].
    

    • 

  • 

    В параграф 5.2. Сохранение сведений PMTU добавлен текст об отбрасывании сообщений ICMPv6 PTB, указывающих MTU меньше минимального IPv6 MTU.
    

    • 

  • 

    В параграф 5.2. Сохранение сведений PMTU добавлено разъяснение о сохранении хостом с несколькими интерфейсами сведений Path MTU для каждого канала.
    

    • 

  • 

    Из параграфа 5.2. Сохранение сведений PMTU удалён текст о Routing Header type 0 (RH0), поскольку этот заголовок отменен RFC 5095. Исключена также устаревшая классификация безопасности.
    

    • 

  • 

    Изменено название параграфа 5.4. Действия уровня пакетирования и текст первого абзаца в нем для обобщения содержимого параграфа на все уровни пакетирования (а не только TCP).
    

    • 

  • 

    Уточнён текст параграфа 5.4. Действия уровня пакетирования в части применения обычных методов повтора передачи уровня пакетирования.
    

    • 

  • 

    Из параграфа 5.4. Действия уровня пакетирования исключён текст, описывающий 4.2 BSD, поскольку он устарел, а также исключена ссылка на TP4.
    

    • 

  • 

    Обновлён текст параграфа 5.5. Проблемы других транспортных протоколов о NFS с включением современных ссылок и удалением устаревших сведений.
    

    • 

  • 

    В раздел 6. Вопросы безопасности добавлен абзац о «чёрных дырах» соединений при отсутствии сообщений PTB, а также сравнение с PLPMTUD.
    

    • 

  • 

    Обновлён параграф Благодарности.
    

    • 

  • 

    Внесены редакторские правки.
    

    • 



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


Спасибо авторам и участникам создания [RFC1191], послужившего основой для этого документа, а также членам рабочей группы IPng за их рецензии и конструктивную критику.


Спасибо также участникам работы над этим обновлением Path MTU Discovery for IP Version 6, включая членов рабочей группы 6MAN, рецензентов от руководства направлением, IESG и особенно Joe Touch и Gorry Fairhurst.


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


Jack McCann


Digital Equipment Corporation


Stephen E. Deering


Retired


Vancouver, British Columbia


Canada


Jeffrey Mogul


Digital Equipment Corporation


Robert M. Hinden (editor)


Check Point Software


959 Skyway Road


San Carlos, CA 94070


United States of America


Email: bob.hinden@gmail.com




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


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


nmalykh@protokols.ru 




1Maximum Transmission Unit — максимальный передаваемый блок.






2Internet Engineering Task Force.






3Internet Engineering Steering Group.






4Denial-of-service — отказ в обслуживании.






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



 							

	
			

									
						Рубрика: RFC					
					|
				
				
				Оставить комментарий

							

		


		
	

	
			

			
RFC 8200 Internet Protocol, Version 6 (IPv6) Specification


			

				Опубликовано 12.07.2017 автором Nikolai Malykh			


					

				
Internet Engineering Task Force (IETF)                        S. Deering
Request for Comments: 8200                                       Retired
STD: 86                                                        R. Hinden
Obsoletes: 2460                                     Check Point Software
Category: Standards Track                                      July 2017
ISSN: 2070-1721



Спецификация протокола IPv6


Internet Protocol, Version 6 (IPv6) Specification


PDF


Аннотация


Этот документ является спецификацией протокола IP версии 6 (IPv6) и отменяет RFC 2460.


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


Документ относится к категории Internet Standards Track.


Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.


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


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


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


К документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).


Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права, этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards, за исключением форматирования документа для публикации или перевода с английского языка на другие языки.






1. Введение


Протокол IP версии 6 (IPv6) представляет собой новую версию протокола Internet (Internet Protocol или IP), разработанную для замены предшествующего протокола IP версии 4 (IPv4) [RFC791]. Основные отличия IPv6 от IPv4 можно разделить на несколько категорий.


    

  • 

    Расширенные возможности адресации
    

    IPv6 расширяет размер адресов IP с 32 до 128 битов для поддержки большего числа уровней иерархии адресов, многократного увеличения числа адресуемых устройств и упрощения процесса автоматической настройки адресов. Расширяемость групповой маршрутизации повышается за счёт добавления поля scope (область действия) в групповые адреса. Определён новый тип адресов — anycast, используемых для передачи пакета одному (любому) узлу из группы.
    

    • 

  • 

    Упрощение формата заголовков
    

    Некоторые поля заголовков IPv4 в новой версии протокола не используются или не обязательны. Это позволяет сократить издержки на обработку пакетов и расход полосы пропускания каналов на передачу заголовков IPv6.
    

    • 

  • 

    Улучшенная поддержка расширений и опций
    

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

    • 

  • 

    Поддержка меток потоков
    

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

    • 

  • 

    Поддержка аутентификации и приватности
    

    В IPv6 добавлены расширения для поддержки проверки подлинности (аутентификации), контроля целостности и (необязательно) конфиденциальности данных.
    

    • 



В этом документе приведена спецификация базового заголовка IPv6, а также изначально определённых расширений и опций заголовков IPv6. Рассмотрены также вопросы, связанные с размером пакетов, семантика меток потоков и классов трафика, а также влияние IPv6 на вышележащие протоколы. Формат и семантика адресов IPv6 рассмотрены в [RFC4291]. Версия ICMP для протокола IPv6, которую должны включать все реализации IPv6, описана в [RFC4443].


Порядок передачи данных для IPv6 совпадает с порядком передачи данных IPv4, определенным в Приложении B к [RFC791].


Примечание. Поскольку этот документ заменяет собой [RFC2460], во всех упомянутых здесь документах ссылки на RFC 2460 следует считать ссылками на данный документ.


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


node — узел 


Устройство, реализующее IPv6.


router — маршрутизатор 


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


host — хост


Любой узел, не являющийся маршрутизатором1.


upper layer — вышележащий уровень


Протокольный уровень, расположенный непосредственно над IPv6. Примерами такого уровня являются транспортные протоколы типа TCP и UDP, протоколы управления типа ICMP, протоколы маршрутизации, такие как OSPF, а также протоколы, «туннелируемые» через IPv6 (т. е., инкапсулированные в пакеты IPv6), такие как IPX (Internetwork Packet Exchange — пакет межсетевого обмена), AppleTalk или самого IPv6.


link — канал


Коммуникационный объект или среда, посредством которых узлы могут взаимодействовать на канальном уровне (уровне, расположенном непосредственно под IPv6). Примерами могут служить сети Ethernet (с мостами или без них), каналы PPP, сети X.25, Frame Relay или ATM, а также туннели сетевого или вышележащих уровней (например, туннели IPv4 или IPv6).


neighbors — соседи


Узлы, подключённые к одному каналу.


interface — интерфейс


Подключение узла к каналу.


address — адрес 


Идентификатор уровня IPv6 для интерфейса или группы интерфейсов.


packet — пакет 


Заголовок IPv6 и данные (payload).


link MTU — максимальный передаваемый блок для канала


Максимальный блок информации (максимальный размер пакета в октетах), который можно передать через канал.


path MTU — максимальный передаваемый блок для пути 


Минимальное значение link MTU среди всех каналов на пути от отправителя к получателю.


3. Формат заголовка IPv6


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Version — версия


4-битовое значение номера версии протокола IP (6).


Traffic Class — класс трафика


8-битовое поле классификатора трафика (7. Классы трафика).


Flow Label — метка потока


20-битовая метка потока (6. Метки потоков).


Payload Length — размер данных


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


Next Header — следующий заголовок


8-битовый селектор, указывающий тип заголовка, следующего сразу после заголовка IPv6. Для этого поля используются те же значения, которые определены для поля Protocol в заголовке IPv4 [IANA-PN].


Hop Limit — предельное число пересылок


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


Source Address — адрес отправителя


128-битовый адрес инициатора пакета (см. [RFC4291]).


Destination Address — адрес получателя


128-битовый адрес получателя пакета (возможно, не конечного, если присутствует заголовок Routing). См. [RFC4291] и параграф 4.4.


4. Заголовки расширений IPv6


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


Заголовки расширения нумеруются значениями из реестра IANA IP Protocol Numbers [IANA-PN] с использованием одинаковых значений для IPv4 и IPv6. При обработке последовательности значений Next Header в пакете первый элемент, не являющийся заголовком расширения [IANA-EH], показывает что следующий элемент в пакете относится к заголовку вышележащего уровня. Если такого заголовка нет, применяется специальное значение No Next Header.


Как показано в примерах, приведённых ниже, пакет IPv6 может не включать расширенных заголовков или содержать один или несколько таких заголовков, каждый из которых указывается полем Next Header предшествующего заголовка.


+---------------+------------------------
| Заголовок IPv6| Заголовок TCP и данные
|               |
| Next Header = |
|      TCP      |
+---------------+------------------------

+---------------+-----------------+------------------------
| Заголовок IPv6|Заголовок Routing| Заголовок TCP и данные
|               |                 |
| Next Header = |  Next Header =  |
|    Routing    |      TCP        |
+---------------+-----------------+------------------------

+---------------+-----------------+------------------+-----------------
| Заголовок IPv6|Заголовок Routing|Заголовок Fragment| Фрагмент 
|               |                 |                  | заголовка TCP 
| Next Header = |  Next Header =  |  Next Header =   | и данные
|    Routing    |    Fragment     |       TCP        |
+---------------+-----------------+------------------+-----------------


Заголовки расширения (за исключением Hop-by-Hop Options) не обрабатываются, не добавляются и не удаляются узлами на пути доставки пакета, пока он не достигнет узла (или группы узлов в случае групповой адресации), указанного полем Destination Address в заголовке IPv6.


Заголовок Hop-by-Hop Options не добавляется и не удаляется промежуточными узлами, но может быть проверен и обработан любым узлом на пути до того, как достигнет узла (или группы узлов в случае групповой адресации), указанного полем Destination Address в заголовке IPv6. При наличии заголовка Hop-by-Hop Options он должен помещаться непосредственно после заголовка IPv6. Его присутствие указывается нулевым значением поля Next Header в заголовке IPv6.


Примечание. Хотя [RFC2460] требует от всех узлов проверки и обработки заголовка Hop-by-Hop Options, сейчас предполагается, что промежуточные узлы будут проверять и обрабатывать Hop-by-Hop Options только в тех случаях, когда это явно задано в их конфигурации.


На узле-получателе обычное демультиплексирование поля Next Header в заголовке IPv6 вызывает модуль для обработки первого заголовка расширения или заголовка вышележащего уровня при отсутствии заголовков расширения. В зависимости от содержимого и семантики заголовка расширения выполняется (или не выполняется) обработка следующего заголовка. Следовательно, заголовки расширения должны обрабатываться строго в порядке их размещения в пакете, получателю недопустимо сканировать пакет для поиска определённого заголовка расширения и обработки этого заголовка до обработки его предшественников.


Если по результату обработки заголовка получателю требуется обработать следующий заголовок, но значение Next Header в текущем заголовке не распознано, пакет следует отбросить и передать его отправителю сообщение ICMP Parameter Problem с ICMP Code = 1 (unrecognized Next Header type encountered) и полем ICMP Pointer, указывающим смещение непонятного значения в исходном пакете. Такие же действия следует выполнять в случае нулевого значения поля Next Header в любом заголовке за исключением базового заголовка IPv6.


Размер каждого заголовка расширения кратен 8 для выравнивания последующих заголовков по границе 8 октетов. Многооктетные поля в каждом заголовке расширения выравниваются по их естественным границам (т. е., поле размером n октетов размещается со смещением от начала заголовка, кратным n для значений n = 1, 2, 4 или 8).


Полная реализация IPv6 включает поддержку следующих заголовков расширения:


Hop-by-Hop Options;

Fragment;

Destination Options;

Routing;

Authentication;

Encapsulating Security Payload.


Первые 4 типа заголовков описаны в этом документе, а два оставшихся — в [RFC4302] и [RFC4303], соответственно. Действующий список заголовков расширения IPv6 можно найти в [IANA-EH].


4.1. Порядок заголовков расширения


При включении в пакет более одного заголовка расширения рекомендуется размещать заголовки в следующем порядке:


IPv6;

Hop-by-Hop Options;

Destination Options2;

Routing;

Fragment;

Authentication3;

Encapsulating Security Payload2;

Destination Options4;

заголовок вышележащего уровня.


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


Если заголовком вышележащего уровня является другой заголовок IPv6 (туннелирование или инкапсуляция IPv6 в IPv6), за ним могут следовать свои заголовки расширения, к которым также относятся приведённые выше рекомендации по порядку следования.


При определении других заголовков расширения должен задаваться порядок их размещения относительно приведённого выше списка.


Узлы IPv6 должны воспринимать и пытаться обрабатывать заголовки расширения при любом порядке и числе вхождений однотипных заголовков расширения в одном пакете. Исключением является заголовок Hop-by-Hop Options, который может присутствовать только непосредственно после заголовка IPv6. Тем не менее, источникам пакетов IPv6 настоятельно рекомендуется включать заголовки расширения в указанном выше порядке, если он не будет изменён последующими спецификациями.


4.2. Опции


Два из определённых в настоящее время заголовков расширения (Hop-by-Hop Options и Destination Options) могут содержать переменное число опций, представленных в формате TLV5, как показано ниже.


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
|  Option Type  |  Opt Data Len |  Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -


Option Type — тип опции


8-битовый идентификатор типа опции.


Opt Data Len — размер данных опции


8-битовое целое число без знака, указывающее размер поля Option Data в октетах.


Option Data — данные опции


Поле переменного размера, определяемое типом опции.


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


Идентификаторы Option Type представляются таким образом, что два старших бита задают действие, которое должен выполнить узел IPv6, если значение Option Type ему неизвестно:


00 пропустить опцию и продолжить обработку заголовка;


01 отбросить пакет;


10 отбросить пакет и, независимо от того, указывает ли поле Destination Address групповой адрес, передать сообщение ICMP Parameter Problem с кодом 2 (нераспознанное значение Option Type) по адресу отправителя (Source Address);


11 отбросить пакет и, если поле Destination Address не содержит групповой адрес, передать сообщение ICMP Parameter Problem с кодом 2 (нераспознанное значение Option Type) по адресу отправителя.


Третий по старшинству бит Option Type указывает, может ли поле Option Data изменяться на пути к адресату. При наличии в пакете заголовка Authentication для любой опции, данные которой могут меняться в пути, значение поля Option Data должно считаться нулевым при расчёте и проверке контрольной суммы пакета.


0 — Option Data не меняется в пути.


1 — Option Data может меняться в пути.


Три описанных выше старших бита считаются частью поля Option Type, но не являются независимыми от типа опции (т. е. конкретная опция указывается всеми битами поля Option Type, а не только 5 младшими битами этого поля).


Заголовки Hop-by-Hop Options и Destination Options используют общее пространство значений Option Type. Однако спецификация конкретной опции может ограничивать применение типа только одним из этих двух заголовков.


Для отдельных опций могут использоваться специфические требования по выравниванию, чтобы многооктетные поля в Option Data выравнивались по естественным границам. Требования по выравниванию для опций задаются с использованием нотации xn+y, показывающей, что поле Option Type должно представлять собой целое число, размер которого в октетах кратен x, со смещением y октетов от начала заголовка. Например,


2n указывает 2-октетное значение с произвольным смещением от начала заголовка;


8n+2 указывает 8-октетное значение со смещением 2 октета.


Имеется для варианта, которые можно применять при необходимости выравнивания опций путём заполнения до границы, кратной 8 октетам. Эти варианты заполнения должны поддерживаться всеми реализациями IPv6.


Pad1 (требований по выравниванию нет)


+-+-+-+-+-+-+-+-+
|       0       |
+-+-+-+-+-+-+-+-+


Опция Pad16 используется для вставки одного октета заполнения в область опций заголовка. Если требуется заполнить более одного октета, следует использовать описанную ниже опцию PadN, а не набор опций Pad1.


PadN (требований по выравниванию нет)


Опция PadN используется для вставки в область Options заголовка двух или более октетов заполнения. Для N октетов заполнения поле Opt Data Len содержит значение N-2, а поле Option Data — N-2 октетов 0.


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
|       1       |  Opt Data Len |  Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -


Рекомендации по формату новых опций приведены в Приложении A.


4.3. Заголовок Hop-by-Hop Options


Заголовок Hop-by-Hop Options используется для передачи дополнительной информации, которая может проверяться и обрабатываться на каждом узле по пути доставки пакета. Заголовок Hop-by-Hop Options идентифицируется значением Next Header = 0 в заголовке IPv6 и использует формат, показанный на рисунке.


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                                                               .
.                            Options                            .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Next Header — следующий заголовок


8-битовый селектор типа заголовка, следующего непосредственно за Hop-by-Hop Options. Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].


Hdr Ext Len — размер заголовка расширения


8-битовое целое число без знака, указывающее размер заголовка в 8-октетных словах без учёта первых 8 октетов.


Options — опции


Поле переменного размера, содержащее одну или множество опций в формате TLV, как описано в параграфе 4.2. Общий размер заголовка Hop-by-Hop Options должен быть кратным 8 октетам.


В этом документе для данного заголовка расширения определены только опции Pad1 и PadN (параграф 4.2).


4.4. Заголовок Routing


Заголовок Routing используется источником пакетов IPv6 для указания одного или множества промежуточных узлов, через которые пакет должен пройти на пути к адресату. Функционально этот заголовок очень похож на опции Loose Source и Record Route в заголовках IPv4. Заголовок Routing указывается значением Next Header = 43 в предшествующем ему заголовке и имеет показанный на рисунке формат.


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       type-specific data                      .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Next Header — следующий заголовок


8-битовый селектор, определяющий тип заголовка, следующего непосредственно за Routing. Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].


Hdr Ext Len — размер заголовка расширения


8-битовое целое число без знака, указывающее размер заголовка в 8-октетных словах без учёта первых 8 октетов.


Routing Type — тип маршрутизации


8-битовый идентификатор конкретного варианта заголовка Routing.


Segments Left — число оставшихся сегментов


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


type-specific data — данные


Поле переменного размера, формат которого определяется значением поля Routing Type. Размер этого поля должен быть таким, чтобы полный размер заголовка Routing был кратен 8 октетам.


Если при обработке полученного пакета узел встречает заголовок Routing с неизвестным значением поля Routing Type, поведение узла определяется значением поля Segments Left, как описано ниже.


Если Segments Left = 0, узел должен игнорировать заголовок Routing и перейти к обработке следующего заголовка в пакете, тип которого указан полем Next Header в заголовке Routing.


Если значение поля Segments Left отлично от нуля, узел должен отбросить пакет и передать сообщение ICMP Parameter Problem с кодом 0 (нераспознанное значение Routing Type) по адресу отправителя.


Если после обработки заголовка Routing получивший пакет узел определяет, что пакет будет пересылаться в канал, для которого значение MTU меньше размера пакета, узел должен отбросить пакет и передать сообщение ICMP Packet Too Big по адресу отправителя.


Определённые в настоящее время заголовки IPv6 Routing и их статус описаны в [IANA-RH]. Рекомендации по распределению значений для IPv6 Routing Header даны в [RFC5871].


4.5. Заголовок Fragment


Заголовок Fragment используется отправителем IPv6 для передачи пакетов, размер которых превышает значение path MTU для адресата7. Заголовок Fragment указывается значением Next Header = 44 в непосредственно предшествующем заголовке и имеет формат, показанный на рисунке.


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Next Header — тип фрагментируемой части


8-битовый селектор, определяющий исходный тип заголовка фрагментируемой части (Fragmentable Part) исходного пакета (см. определение ниже). Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].


Reserved — резерв


8-битовое резервное поле. При передаче это поле заполняется нулями, а на приёмной стороне игнорируется.


Fragment Offset — смещение фрагмента


13-битовое целое число без знака, указывающее смещение (в 8-октетных блоках) данных, размещённых вслед за этим заголовком, относительно начала фрагментируемой части исходного пакета.


Res


2-битовое резервное поле. При передаче это поле заполняется нулями, а на приёмной стороне игнорируется.


Флаг M


1 — есть ещё фрагменты, 0 — последний фрагмент.


Identification — идентификация


32 бита (см. описание ниже).


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


Для каждого пакета, который будет фрагментироваться, узел-источник генерирует значение Identification. Это значение для фрагментированного пакета должно отличаться от значений для фрагментированных пакетов, переданных «недавно»8 с такими же значениями полей Source Address и Destination Address. При наличии заголовка Routing для фрагментированных пакетов Destination Address трактуется, как адрес конечного получателя.


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


+------------------+-------------------------+---//----------------+
|  Per-Fragment    | Extension & Upper-Layer |   Fragmentable      |
|    Headers       |       Headers           |      Part           |
+------------------+-------------------------+---//----------------+


Часть Per-Fragment Headers должна состоять из заголовка IPv6 и всех заголовков расширения, которые должны обрабатываться узлами на пути к получателю, т. е. всех заголовков вплоть до Routing (при наличии) или Hop-by-Hop Options (при наличии), включительно. Если ни одного из двух упомянутых заголовков нет, эта часть не включает заголовков расширения.


Следующая часть включает все оставшиеся заголовки расширения, которые не вошли в Per-Fragment Headers. При этом заголовки ESP9 не считаются заголовками расширения. Заголовком вышележащего уровня (Upper-Layer header) является первый заголовок вышележащего уровня, не являющийся заголовком расширения IPv6. Примерами такого заголовка могут быть заголовки TCP, UDP, IPv4, IPv6, ICMPv6, ESP.


Fragmentable Part представляет оставшуюся часть пакета после заголовка вышележащего уровня или любого другого заголовка (например, основного заголовка IPv6 или заголовка расширения, в котором поле Next Header имеет значение No Next Header).


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


Фрагменты передаются в отдельных «фрагментированных пакетах», как показано ниже.


Исходный пакет


+-----------------+-----------------+--------+--------+-//-+--------+
|  Per-Fragment   |Ext & Upper-Layer|  first | second |    |  last  |
|    Headers      |    Headers      |fragment|fragment|....|fragment|
+-----------------+-----------------+--------+--------+-//-+--------+


Фрагментированные пакеты


+------------------+---------+-------------------+----------+
|  Per-Fragment    |Fragment | Ext & Upper-Layer |  first   |
|    Headers       | Header  |   Headers         | fragment |
+------------------+---------+-------------------+----------+
+------------------+--------+-------------------------------+
|  Per-Fragment    |Fragment|    second                     |
|    Headers       | Header |   fragment                    |
+------------------+--------+-------------------------------+
                      o
                      o
                      o
+------------------+--------+----------+
|  Per-Fragment    |Fragment|   last   |
|    Headers       | Header | fragment |
+------------------+--------+----------+


Пакет с первым фрагментом состоит из 4 частей, показанных ниже.


    

  1. 

    Заголовки Per-Fragment исходного пакета с полем Payload Length в исходном заголовке IPv6, измененным в соответствии с размером данного фрагмента (без учёта самого заголовка IPv6), и полем Next Header в последнем заголовке Per-Fragment, содержащим значение 44.
    

    2. 

  2. 

    Заголовок Fragment, содержащий перечисленные ниже поля.
    

    3. 



Next Header со значением, указывающим первый заголовок после заголовков Per-Fragment в исходном пакете.


Значение Fragment Offset, указывающее смещение фрагмента (в 8-октетных блоках) от начала Fragmentable Part исходного пакета. В первом (самом левом) фрагменте Fragment Offset = 0.


Флаг M со значением 1, поскольку это первый фрагмент.


Значение Identification, созданное для исходного пакета.


    

  1. 

    Заголовки расширения (при наличии) и заголовок вышележащего уровня. Эти заголовки должны включаться в первый фрагмент10.
    

    2. 

  2. 

    Первый фрагмент.
    

    3. 



Пакеты следующих фрагментов состоят из трёх частей.


    

  1. 

    Заголовки Per-Fragment исходного пакета с полем Payload Length в исходном заголовке IPv6, указывающим размер данного фрагмента (без учёта самого заголовка IPv6), и полем Next Header в последнем заголовке Per-Fragment со значением 44.
    

    2. 

  2. 

    Заголовок Fragment содержащий перечисленные ниже поля.
    

    3. 



Next Header со значением, указывающим первый заголовок после заголовков Per-Fragment исходного пакета.


Значение Fragment Offset, указывающее смещение фрагмента (в 8-октетных блоках) от начала Fragmentable Part исходного пакета.


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


Значение Identification, созданное для исходного пакета.


    

  1. 

    Сам фрагмент.
    

    2. 



При фрагментировании пакета перекрытие фрагментов недопустимо.


На приёмной стороне фрагменты пакета собираются заново в исходный пакет, как показано на рисунке.


+---------------+-----------------+---------+--------+-//--+--------+
| Per-Fragment  |Ext & Upper-Layer|  first  | second |     | last   |
|    Headers    |     Headers     |frag data|fragment|.....|fragment|
+---------------+-----------------+---------+--------+-//--+--------+


Сборка фрагментов выполняется в соответствии с приведёнными ниже правилами.


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


Заголовки Per-Fragment собранного пакета включают все заголовки вплоть (но не включая) до заголовка Fragment пакета с первым фрагментом (т. е. пакета с Fragment Offset = 0), с учётом указанных ниже изменений.


Поле Next Header последнего заголовка Per-Fragment берётся из поля Next Header в заголовке Fragment пакета с первым фрагментом.


Значение поля Payload Length в собранном пакете вычисляется на основе размера заголовков Per-Fragment, а также размера и смещения последнего фрагмента. Ниже приведена формула для расчёта.


PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last


где


PL.orig  =  поле Payload Length собранного пакета.
PL.first =  поле Payload Length первого фрагмента.
FL.first =  размер фрагмента, следующего после заголовка Fragment в пакете первого фрагмента.
FO.last  =  поле Fragment Offset заголовка Fragment в пакете последнего фрагмента.
FL.last  =  размер фрагмента после заголовка Fragment в пакете последнего фрагмента.


Fragmentable Part собираемого пакета складывается из фрагментов, следующих за заголовком Fragment в каждом из фрагментированных пакетов. Размер каждого фрагмента вычисляется путём вычитания из значения поля Payload Length размера всех заголовков, содержащихся между заголовком IPv6 и самим фрагментом, относительное расположение Fragmentable Part определяется на основе значения Fragment Offset.


Заголовок Fragment в собранном пакете не присутствует.


Если фрагмент является полной дейтаграммой (Fragment Offset = 0 и флаг M сброшен), он не требует какой-либо сборки и его следует обрабатывать как полностью собранный пакет (скорректировать значения Next Header и Payload Length, удалить заголовок Fragment и т. д.). Любые другие фрагменты, соответствующие этому пакету (с такими же значениями IPv6 Source Address, IPv6 Destination Address и Fragment Identification), следует обрабатывать независимо.


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


    

  • 

    Если в течение 60 секунд с момента приёма первого фрагмента получены не все фрагменты, требуемые для сборки, сборка должна быть прервана, а все полученные фрагменты отброшены. Если первый фрагмент (пакет со значением Fragment Offset = 0) был получен, отправителю этого фрагмента следует передать сообщение ICMP Time Exceeded (истекло время сборки фрагментов).
    

    • 

  • 

    Если размер фрагмента, определённый из значения поля Payload Length в заголовке пакета с фрагментом, не кратен 8 октетам, а флаг M = 1, этот фрагмент должен отбрасываться, а отправителю фрагмента следует передать сообщение ICMP Parameter Problem с кодом 0, указывающее на поле Payload Length пакета с фрагментом.
    

    • 

  • 

    Если значения размера и смещения для фрагмента таковы, что значение поля Payload Length собранного из фрагментов пакета будет превышать 65 535 октетов, этот фрагмент должен быть отброшен, а его отправителю следует передать сообщение ICMP Parameter Problem с кодом 0, указывающее на поле Fragment Offset в пакете с фрагментом.
    

    • 

  • 

    Если первый фрагмент не включает всех заголовков до заголовка Upper-Layer, фрагмент следует отбросить, а его отправителю передать сообщение ICMP Parameter Problem с кодом 3 и полем Pointer = 0.
    

    • 

  • 

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

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

    • 



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


Число и содержимое заголовков, предшествующих заголовку Fragment в разных фрагментах одного исходного пакета могут различаться. Независимо от того, какие заголовки присутствуют в каждом фрагменте перед заголовком Fragment, они обрабатываются до того, как фрагменты будут помещены в очередь на сборку. В собранном пакете остаются лишь заголовки из фрагментированного пакета с Offset = 0.


Значения Next Header в заголовках Fragment различных фрагментов одного исходного пакета могут различаться. Для сборки фрагментов используется только значение из пакета, содержащего фрагмент с Offset = 0.


Другие поля в заголовке IPv6 также могут изменяться в процессе сборки фрагментов. Спецификации, использующие такие поля, могут включать дополнительные инструкции, если базового механизма с использованием значений лишь из фрагмента с Offset = 0 недостаточно. Например, в параграфе 5.3 [RFC3168] описано, как комбинируются биты ECN из разных фрагментов для получения ECN в собранном пакете.


4.6. Заголовок Destination Options


Заголовок Destination Options используется для передачи дополнительной информации, которая будет просматриваться только на конечный узлах. Заголовок Destination Options указывается значением Next Header = 60 в предшествующем непосредственно заголовке и имеет формат, показанный на рисунке.


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                                                               .
.                            Options                            .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Next Header — следующий заголовок


8-битовый селектор, определяющий тип заголовка, следующего непосредственно за Destination Options. Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].


Hdr Ext Len — размер заголовка расширения


8-битовое целое число без знака, указывающее размер заголовка в 8-октетных словах без учёта первых 8 октетов.


Options — опции


Поле переменной длины, такой, что полный размер заголовка Destination Options кратен 8 октетам. Поле опций содержит одну или множество опций в формате TLV, как описано в параграфе 4.2.


В этом документе определены только две опции получателя (Pad1 и PadN), описанные в параграфе 4.2.


Отметим, что существует два способа представления дополнительной информации для получателя в пакетах IPv6 — в виде опции заголовка Destination Options или в виде отдельного заголовка расширения. Примерами второго варианта могут служить заголовки Fragment и Authentication. Выбор конкретного варианта зависит от того, какие действия желательны на узле-адресате в случае непонимания дополнительной информации.


    

  • 

    Если желательным действием является отбрасывание пакета получателем и передача (если адрес получателя не является групповым) отправителю сообщения ICMP Unrecognized Type, дополнительная информация может быть представлена в отдельном заголовке или в опции заголовка Destination Options со значением 11 в двух старших битах поля Option Type. Выбор конкретного варианта может определяться размером опции, более эффективным выравниванием или разбором.
    

    • 

  • 

    Если желательно иное действие, дополнительная информация должна представляться в виде опции заголовка Destination Options, для которого два старших бита поля Option Type имеют значение 00, 01 или 10, задающее требуемое действие (4.2. Опции).
    

    • 



4.7. Нет следующего заголовка


Значение 59 в поле Next Header заголовка IPv6 или любого заголовка расширения говорит об отсутствии последующих заголовков в пакете. Если поле Payload Length в заголовке IPv6 показывает наличие октетов после завершения заголовка, в котором Next Header = 59, эти октеты должны игнорироваться и пересылаться без изменений.


4.8. Определение новых расширений заголовка и опций


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


Примечание. Новые заголовки расширения, требующие поэтапной (hop-by-hop) обработки, добавлять недопустимо, поскольку, как отмечено в разделе 4 данного документа, заголовок Hop-by-Hop Options является единственным заголовком расширения с поэтапной обработкой.


Создавать новые опции с поэтапной (hop-by-hop) обработкой не рекомендуется, поскольку на узлах может быть задано игнорирование заголовка Hop-by-Hop Options, отбрасывание пакетов с таким заголовком или направление пакетов по пути медленной обработки. Разработчикам, предполагающим определить новые опции hop-by-hop, следует принимать это во внимание и чётко обосновать необходимость любой новой опции hop-by-hop до ее стандартизации.


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


Если новые заголовки расширения всё-таки определяются, они должны использовать показанный ниже формат.


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                                                               .
.                  Header-Specific Data                         .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Next Header — следующий заголовок


8-битовый селектор, определяющий тип заголовка, следующего непосредственно после заголовка расширения. Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [IANA-PN].


Hdr Ext Len — размер заголовка расширения


8-битовое целое число без знака, указывающее размер заголовка в 8-октетных словах без учёта первых 8 октетов.


Header Specific Data 


Поле переменного размера в зависимости от расширения заголовка.


5. Размер пакетов


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


Каналы с настраиваемым значением MTU (например, PPP [RFC1661]) должны настраиваться на использование значений MTU не менее 1280 октетов. Рекомендуется устанавливать значение MTU не менее 1500 октетов для обеспечения возможности инкапсуляции (например, туннелирования) без фрагментации на уровне IPv6.


Из каждого канала, к которому узел подключён непосредственно, узел должен быть способен принимать пакеты размером MTU для этого канала.


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


Для передачи пакетов, размер которых превышает path MTU, узел может использовать заголовок IPv6 Fragment для фрагментации пакета на стороне отправителя и сборки фрагментов на приёмной стороне. Однако такой фрагментации следует избегать во всех приложениях, которые могут подстраивать размер пакетов под измеренное значение path MTU (например, до 1280 октетов).


Узел должен быть способен воспринимать фрагментированные пакеты, размер которых после сборки достигает 1500 октетов, и может воспринимать пакеты, размер которых после сборки фрагментов превышает 1500 октетов. Протоколам или приложениям вышележащего уровня, зависящим от фрагментации IPv6, для передачи пакетов с размером больше MTU для пути не следует передавать пакетов размером более 1500 октетов, если нет уверенности в том, что получатель может собирать из фрагментов пакеты размером более 1500 октетов .


6. Метки потоков


20-битовое поле Flow Label в заголовке IPv6 используется отправителем для обозначения последовательности пакетов, которую в сети следует считать единым потоком. Определение IPv6 Flow Label приведено в [RFC6437].


7. Классы трафика


8-битовое поле Traffic Class в заголовке IPv6 используется в сети для управления трафиком. Значения битов Traffic Class в принятом пакете или фрагменте могут отличаться от установленных отправителем.


Использование поля Traffic Class для дифференцированных услуг (Differentiated Services) и явного уведомления о перегрузке (Explicit Congestion Notification или ECN) задано в [RFC2474] и [RFC3168].


8. Протоколы вышележащего уровня


8.1. Контрольные суммы


Любой транспортный протокол или иной протокол вышележащего уровня, который включает адреса из заголовка IP в расчёт контрольной суммы, должен быть изменён для использования с протоколом IPv6, в котором применяются 128-битовые адреса IPv6 взамен 32-битовых адресов IPv4. Приведённый рисунок показывает псевдозаголовок TCP и UDP для IPv6.


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Upper-Layer Packet Length                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      zero                     |  Next Header  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    

  • Если пакет IPv6 включает заголовок Routing, поле Destination Address, используемое в псевдозаголовке, указывает конечного получателя. На источнике этот адрес будет последним элементом заголовка Routing, на приёмной стороне этот адрес будет указан в поле Destination Address заголовка IPv6.
    • 

  • Значение Next Header в псевдозаголовке указывает протокол вышележащего уровня (например, 6 для протокола TCP или 17 для UDP). Оно будет отличаться от значения Next Header в заголовке IPv6, если между этим заголовком и заголовком вышележащего уровня имеются заголовки расширения.
    • 

  • Поле Upper-Layer Packet Length в псевдозаголовке содержит размер заголовка и данных вышележащего уровня (например, заголовка и данных TCP). Некоторые протоколы вышележащего уровня поддерживают собственную информацию о размере (например, поле Length в заголовке UDP), для таких протоколов это будет размер, указанный в псевдозаголовке. Другие протоколы (такие, как TCP) не поддерживают своих данных о размере и размер, указанный в псевдозаголовке, будет значением поля Payload Length из заголовка IPv6 за вычетом размера всех заголовков расширения между заголовками IPv6 и вышележащего уровня.
    • 

  • В отличие от IPv4, поле контрольной суммы для пакетов UDP, порождаемых узлом IPv6, не является опциональным, т. е. при генерации пакета UDP узел IPv6 должен рассчитать контрольную сумму UDP для пакета и псевдозаголовка и при получении нулевого значения контрольной суммы заменить его значением FFFF для включения в заголовок UDP. Получатель IPv6 должен отбрасывать пакеты UDP с нулевым значением контрольной суммы и этот факт следует записывать в системный журнал.
    • 

  • Как исключение для принятого по умолчанию поведения, протоколы, использующие UDP для туннельной инкапсуляции, могут разрешать нулевые значения контрольной суммы (zero-checksum mode) для конкретного порта или набора портов при отправке и/или приёме пакетов. Каждый узел, поддерживающий режим zero-checksum, должен следовать рекомендациям документа «Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums» [RFC6936].
    • 



Протокол ICMP для IPv6 [RFC4443] включает описанный выше псевдозаголовок в расчёт контрольной суммы (в отличие от ICMP для IPv4, где псевдозаголовок не учитывается в контрольной сумме). Это сделано для защиты ICMP от ошибочной доставки или повреждения тех полей в заголовках IPv6, от которых зависит ICMP и которые, в отличие от IPv4, не учитывается в контрольной сумме сетевого уровня. Поле Next Header в псевдозаголовке для ICMP содержит значение 58, указывающее версию IPv6 для протокола ICMP.


8.2. Максимальный срок жизни пакета


В отличие от IPv4, узлы IPv6 не обязаны соблюдать максимальное время жизни пакетов. По этой причине поле TTL (Time to Live) протокола IPv4 переименовано в «максимальное число интервалов» (Hop Limit) в IPv6. На практике очень немногие реализации IPv4 соответствуют требованиям по ограничению времени жизни пакетов, поэтому внесённое в протокол изменение не имеет существенного практического значения. Любой протокол вышележащего уровня, который опирается на сетевой уровень (IPv4 или IPv6) для ограничения времени жизни пакетов, должен быть обновлён путём обеспечения собственных механизмов детектирования и отбрасывания устаревших пакетов.


8.3. Максимальный размер данных вышележащего уровня


При расчёте максимального размера данных, доступного протоколу вышележащего уровня, этот протокол должен принимать во внимание больший размер заголовков IPv6 по сравнению с IPv4. Например, в IPv4 опция TCP MSS11 рассчитывается как максимальный размер пакета (принятый по умолчанию или полученный от Path MTU Discovery) за вычетом 40 октетов (20 октетов минимального заголовка IPv4 и 20 октетов минимального заголовка TCP). При использовании TCP с протоколом IPv6 значение MSS должно рассчитываться как максимальный размер пакета за вычетом 60 октетов, поскольку размер минимального заголовка IPv6 (без заголовков расширения) на 20 октетов превышает минимальный размер заголовка IPv4.


8.4. Отклики на пакеты с заголовками Routing


Когда протокол вышележащего уровня шлёт один или множество пакетов в ответ на принятый пакет с заголовком Routing, в пакеты откликов недопустимо включать заголовок Routing, который будет создаваться автоматически путём обращения полученного заголовка Routing, пока не будет проверена целостность и подлинность поля Source Address и заголовка Routing (например с помощью заголовка Authentication из полученного пакета). Иными словами, в ответ на полученные пакеты с заголовком Routing можно передавать только следующие типы пакетов:


    

  • 

    пакеты отклика без заголовков Routing;
    

    • 

  • 

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

    • 

  • 

    пакеты отклика с заголовками Routing, полученными путём обращения заголовка Routing из принятого пакета тогда и только тогда, когда поле Source Address и заголовок Routing в полученном пакете были проверены отвечающей стороной.
    

    • 



9. Взаимодействие с IANA


В RFC 2460 указано множество реестров IANA, включая:


    

  • 

    Internet Protocol Version 6 (IPv6) Parameters [IANA-6P];
    

    • 

  • 

    Assigned Internet Protocol Numbers [IANA-PN];
    

    • 

  • 

    ONC RPC Network Identifiers (netids) [IANA-NI];
    

    • 

  • 

    Network Layer Protocol Identifiers (NLPIDs) of Interest [IANA-NL];
    

    • 

  • 

    Protocol Registries [IANA-PR].
    

    • 



Агентство IANA обновило эти реестры ссылками на данный документ.


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


IPv6 с точки зрения базового формата и передачи пакетов имеет параметры безопасности похожие на IPv4. Основные проблемы безопасности перечислены ниже.


    

  • 

    Перехват — элементы сети на пути передачи могут видеть целиком (содержимое и метаданные) каждую дейтаграмму IPv6.
    

    • 

  • 

    Повторное использование (Replay) — атакующий может сохранить перехваченные пакеты и повторно передать их тому же адресату.
    

    • 

  • 

    Вставка пакетов — атакующий может подделать пакеты, придав им нужные свойства, и отправить их в сеть.
    

    • 

  • 

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

    • 

  • 

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

    • 

  • 

    MITM-атаки12 — атакующий может разорвать путь передачи, представившись отправителю получателем, а получателю отправителем.
    

    • 

  • 

    DoS-атаки13 — атакующий передаёт большие объёмы легитимного трафика адресату с целью перегрузки последнего.
    

    • 



Пакеты IPv6 можно защитить от просмотра, повторного использования, вставки, изменения и MITM-атак с помощью «Security Architecture for the Internet Protocol» [RFC4301]. В дополнение к этому можно применять протоколы типа TLS14 или SSH15 для защиты трафика приложений, передаваемого по протоколу IPv6.


Не задано механизма защиты от DoS-атак. Методы защиты от атак на службы выходят за рамки этого документа.


Адреса IPv6 существенно длиннее адресов IPv4 и это осложняет сканирование адресного пространства Internet или даже одной сети (например, ЛВС). Дополнительная информация приведена в [RFC7707].


Предполагается, что адреса узлов IPv6 станут «более видимыми» в сети Internet по сравнению с адресами IPv4, поскольку технологии трансляции адресов будут применяться реже. Это создаёт некоторые добавочные проблемы приватности за счёт упрощения идентификации конечных точек. Дополнительная информация приведена в [RFC7721].


Архитектура заголовков расширения IPv6 значительно расширяет возможности, но и вызывает новые проблемы безопасности. Как отмечено ниже, вопросы, связанные с заголовками расширения Fragment, были решены, однако очевидно, что любое новое расширение потребует тщательной проверки в плане безопасности и взаимодействия с имеющимися заголовками расширения. Дополнительная информация дана в [RFC7045].


Данная версия спецификации IPv6 снимает множество проблем безопасности, присущих прежней версии спецификации IPv6 [RFC2460]. Эти проблемы перечислены ниже.


    

  • 

    Пересмотрен текст по обработке фрагментов, являющихся полными дейтаграммами (Fragment Offset = 0 и M = 0). При получении такого пакета его следует трактовать, как собранный из фрагментов. Все остальные соответствующие фрагменты следует обрабатывать независимо. Процесс фрагментации был изменён для предотвращения фрагментов, являющихся полными дейтаграммами (Fragment Offset = 0 и M = 0). Дополнительная информация представлена в [RFC6946] и [RFC8021].
    

    • 

  • 

    Из раздела 5 исключён параграф, требовавший включения заголовка Fragment в исходящие пакеты при получении сообщения ICMP Packet Too Big с информацией о том, что Next-Hop MTU < 1280. Дополнительная информация приведена в [RFC6946].
    

    • 

  • 

    Изменён текст, относящийся к перекрытию фрагментов IPv6, и узлам теперь недопустимо создавать такие фрагменты. Введено требование отбрасывания (без уведомления) дейтаграммы целиком, если в процессе сборки обнаружилось наложение фрагментов. Добавлено разъяснение, что передавать сообщение ICMP в таких случаях не следует. Дополнительная информация приведена в [RFC5722].
    

    • 

  • 

    Пересмотрен текст в части фрагментации заголовков и сейчас все заголовки вплоть до первого заголовка вышележащего уровня должны помещаться в первый фрагмент. Дополнительная информация приведена в [RFC7112].
    

    • 

  • 

    Учтены обновления из [RFC5095] и [RFC5871] в части удаления текста с описанием заголовков Routing типа 0 (RH0), с указанием того, что рекомендации по этим заголовка приведены в RFC 5871, а тип RH0 удалён из списка требуемых заголовков расширений.
    

    • 



Вопросы безопасности, относящиеся к отдельным частям IPv6, включая адресацию, ICMPv6, Path MTU Discovery и т. п., рассмотрены в соответствующих спецификациях.


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


11.1. Нормативные документы


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


[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.


[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.


[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.


[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.


[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, «IPv6 Flow Label Specification», RFC 6437, DOI 10.17487/RFC6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.


11.2. Дополнительная литература


[Err2541] RFC Errata, Erratum ID 2541, RFC 2460.


[Err4279] RFC Errata, Erratum ID 4279, RFC 2460.


[Err4657] RFC Errata, Erratum ID 4657, RFC 2460.


[Err4662] RFC Errata, Erratum ID 4662, RFC 2460.


[IANA-6P] IANA, «Internet Protocol Version 6 (IPv6) Parameters», <https://www.iana.org/assignments/ipv6-parameters>.


[IANA-EH] IANA, «IPv6 Extension Header Types», <https://www.iana.org/assignments/ipv6-parameters>.


[IANA-NI] IANA, «ONC RPC Network Identifiers (netids)», <https://www.iana.org/assignments/rpc-netids>.


[IANA-NL] IANA, «Network Layer Protocol Identifiers (NLPIDs) of Interest», <https://www.iana.org/assignments/nlpids>.


[IANA-PN] IANA, «Protocol Numbers», <https://www.iana.org/assignments/protocol-numbers>.


[IANA-PR] IANA, «Protocol Registries», <https://www.iana.org/protocols>.


[IANA-RH] IANA, «Routing Types», <https://www.iana.org/assignments/ipv6-parameters>.


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


[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.


[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.


[RFC4302] Kent, S., «IP Authentication Header», RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>.


[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.


[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, «Deprecation of Type 0 Routing Headers in IPv6», RFC 5095, DOI 10.17487/RFC5095, December 2007, <http://www.rfc-editor.org/info/rfc5095>.


[RFC5722] Krishnan, S., «Handling of Overlapping IPv6 Fragments», RFC 5722, DOI 10.17487/RFC5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>.


[RFC5871] Arkko, J. and S. Bradner, «IANA Allocation Guidelines for the IPv6 Routing Header», RFC 5871, DOI 10.17487/RFC5871, May 2010, <http://www.rfc-editor.org/info/rfc5871>.


[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, «A Uniform Format for IPv6 Extension Headers», RFC 6564, DOI 10.17487/RFC6564, April 2012, <http://www.rfc-editor.org/info/rfc6564>.


[RFC6936] Fairhurst, G. and M. Westerlund, «Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums», RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.


[RFC6946] Gont, F., «Processing of IPv6 «Atomic» Fragments», RFC 6946, DOI 10.17487/RFC6946, May 2013, <http://www.rfc-editor.org/info/rfc6946>.


[RFC7045] Carpenter, B. and S. Jiang, «Transmission and Processing of IPv6 Extension Headers», RFC 7045, DOI 10.17487/RFC7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>.


[RFC7112] Gont, F., Manral, V., and R. Bonica, «Implications of Oversized IPv6 Header Chains», RFC 7112, DOI 10.17487/RFC7112, January 2014, <http://www.rfc-editor.org/info/rfc7112>.


[RFC7707] Gont, F. and T. Chown, «Network Reconnaissance in IPv6 Networks», RFC 7707, DOI 10.17487/RFC7707, March 2016, <http://www.rfc-editor.org/info/rfc7707>.


[RFC7721] Cooper, A., Gont, F., and D. Thaler, «Security and Privacy Considerations for IPv6 Address Generation Mechanisms», RFC 7721, DOI 10.17487/RFC7721, March 2016, <http://www.rfc-editor.org/info/rfc7721>.


[RFC7739] Gont, F., «Security Implications of Predictable Fragment Identification Values», RFC 7739, DOI 10.17487/RFC7739, February 2016, <http://www.rfc-editor.org/info/rfc7739>.


[RFC8021] Gont, F., Liu, W., and T. Anderson, «Generation of IPv6 Atomic Fragments Considered Harmful», RFC 8021, DOI 10.17487/RFC8021, January 2017, <http://www.rfc-editor.org/info/rfc8021>.


[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, «Path MTU Discovery for IP version 6», STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <http://www.rfc-editor.org/info/rfc8201>.


Приложение A. Рекомендации по формату опций


В этом приложении приведены некоторые рекомендации по расположению полей в новых опциях для использования с заголовками расширения Hop-by-Hop Options и Destination Options, как описано в параграфе 4.2. Рекомендации базируются на следующих допущениях:


    

  • 

    желательно выравнивать многооктетные поля в Option Data по их естественным границам — т. е. поля размером n октетов следует размещать с кратным n смещением от начала заголовка Hop-by-Hop Options или Destination Options (для n = 1, 2, 4, 8);
    

    • 

  • 

    желательно минимизировать размер заголовков Hop-by-Hop Options и Destination Options с учётом того, что размер заголовка должен быть кратным 8 октетам;
    

    • 

  • 

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

    • 



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


Пример 1


Если для опции X требуется два поля данных, размером 8 и 4 октета, их следует расположить, как показано на рисунке.


                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                | Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         4-октетное поле                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         8-октетное поле                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Выравнивание должно быть выполнено по формуле 8n+2, чтобы 8-октетное поле начиналось с кратным 8 смещением от начала содержащего опцию заголовка. Схема полного заголовка Hop-by-Hop Options или Destination Options, содержащего эту опцию, показана на рисунке.


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  | Hdr Ext Len=1 | Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         4-октетное поле                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         8-октетное поле                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Пример 2


Опция Y включает три поля размером 4, 2 и 1 октет, они будут располагаться, как показано на рисунке.


                                                +-+-+-+-+-+-+-+-+
                                                | Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | 1-октет. поле |         2-октетное поле       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         4-октетное поле                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Выравнивание осуществляется по формуле 4n+3, чтобы 4-октетное поле имело кратное 4 смещение от начала содержащего опцию заголовка. Схема полного заголовка Hop-by-Hop Options или Destination Options, содержащего эту опцию, показана на рисунке.


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | 1-октет. поле |         2-октетное поле       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         4-октетное поле                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PadN Option=1 |Opt Data Len=2 |       0       |       0       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Пример 3


Заголовок Hop-by-Hop Options или Destination Options с опциями X и Y из примеров 1 и 2 будет иметь один из приведённых ниже форматов в зависимости от порядка расположения опций


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         4-октетное поле                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         8-октетное поле                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PadN Option=1 |Opt Data Len=1 |       0       | Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | 1-октет. поле |         2-октетное поле       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         4-октетное поле                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PadN Option=1 |Opt Data Len=2 |       0       |       0       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | 1-октет. поле |         2-октетное поле       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         4-октетное поле                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PadN Option=1 |Opt Data Len=4 |       0       |       0       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       0       |       0       | Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         4-октетное поле                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                         8-октетное поле                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Приложение B. Отличия от RFC 2460


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


    

  • 

    Удалено упоминание IP Next Generation в аннотации (Abstract).
    

    • 

  • 

    В раздел 1 добавлен текст, указывающий, что порядок передачи данных совпадает с принятым для протокола IPv4 в RFC 791.
    

    • 

  • 

    Уточнён текст раздела 3 в части декрементирования Hop Limit.
    

    • 

  • 

    Добавлено разъяснение, что заголовки расширения (кроме Hop-by-Hop Options) не обрабатываются, не добавляются и не удаляются узлами на пути доставки пакетов.
    

    • 

  • 

    Требование по обработке заголовка Hop-by-Hop Options заменено на «может» и добавлено примечание, указывающее ожидания в части заголовка Hop-by-Hop Options.
    

    • 

  • 

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

    • 

  • 

    В конце раздела 4 добавлена ссылка на реестр IANA IPv6 Extension Header Types.
    

    • 

  • 

    Включены обновления из RFC 5095 и RFC 5871 с целью удалить описание RH0 и указать, что рекомендации по для Routing указаны в RFC 5871, а тип RH0 исключён из списка требуемых заголовков расширения.
    

    • 

  • 

    Пересмотрен параграф 4.5 в части фрагментации IPv6 с учётом обновлений из RFC 5722, RFC 6946, RFC 7112 и RFC 8021.
    

      

    • 

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

      • 

    • 

      Изменён текст, относящийся к перекрытию фрагментов IPv6, и узлам теперь недопустимо создавать такие фрагменты. Введено требование отбрасывания (без уведомления) дейтаграммы целиком, если в процессе сборки обнаружилось наложение фрагментов. Добавлено разъяснение, что передавать сообщение ICMP в таких случаях не следует.
      

      • 

    • 

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

      • 

    • 

      Обновлён текст в части обработки заголовков Fragment для случая точного совпадения фрагментов.
      

      • 

    • 

      Обновлён текст описания заголовка Fragment в части включения AH16 и случая No Next Header.
      

      • 

    • 

      Вместо термина Unfragmentable Headers используется термин Per-Fragment headers в тексте, посвящённом заголовку Fragment.
      

      • 

    • 

      Из раздела 5 удалён абзац, требовавший включения заголовка Fragment в исходящие пакеты ICMP Packet Too Big с информацией о том, что Next-Hop MTU < 1280.
      

      • 

    • 

      Изменён текст, проясняющий ограничение MTU и 8-байтовые ограничения, а также отмечающий ограничения для заголовков в первом фрагменте.
      

      • 

    

    • 

  • 

    В параграф 4.5 добавлен текст, поясняющий, что некоторые поля в заголовке IPv6 могут изменяться в процессе сборки фрагментов, а также возможность задания дополнительных инструкций по сборке в других спецификациях (см., например, параграф 5.3 в [RFC3168]).
    

    • 

  • 

    Включено обновление из RFC 6564 в форме нового параграфа 4.8 с рекомендациями по определению новых заголовков расширения и опций.
    

    • 

  • 

    В раздел 5 добавлен текст, определяющий минимальное значение IPv6 MTU для канала.
    

    • 

  • 

    Упрощён текст раздела 6, относящийся к меткам потоков (Flow Label) и удалено Приложение A (Семантика и применение поля Flow Label). Вместо прежнего текста добавлена ссылка на действующую спецификацию поля IPv6 Flow Label в [RFC6437] и поля Traffic Class в [RFC2474] и [RFC3168].
    

    • 

  • 

    В раздел 8 включено обновление из RFC 6935 (IPv6 and UDP Checksums for Tunneled Packets). Добавлено исключение из принятого по умолчанию поведения при обработке пакетов UDP с нулевой контрольной суммой для туннелей.
    

    • 

  • 

    В разделе 9. Взаимодействие с IANA ссылки на RFC 2460 заменены ссылками на данный документ.
    

    • 

  • 

    Пересмотрен и расширен раздел 10. Вопросы безопасности.
    

    • 

  • 

    В раздел «Благодарности» добавлен текст с благодарностями авторам обновлённых документов.
    

    • 

  • 

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

    • 

  • 

    Внесены изменения, обусловленные информацией об ошибках RFC 2460.
    

    Erratum ID 2541 [Err2541] — отмечено, что RFC 2460 не обновляет RFC 2205, где размер метки потока был изменён на 24 бита с 20, заданных RFC 1883. Эта проблема была решена в RFC 6437, где определены метки потоков. Данная спецификация упоминает RFC 6437. Других изменений не требуется.
    

    Erratum ID 4279 [Err4279] — отмечено, что в спецификации не описано поведение пересылающего узла при получении пакетов с Hop Limit = 0. В разделе 3 данной спецификации проблема устранена.
    

    Erratum ID 4657 [Err4657] — предложено отказаться от добавления заголовков расширения на всех узлах, кроме источника пакета. Вопрос решён в разделе 4. Заголовки расширений IPv6.
    

    Erratum ID 4662 [Err4662] — предложено отказаться от проверки, обработки, изменения, добавления и удаления заголовков расширения (с единственным исключением) на промежуточных узлах в пути доставки. Вопрос решён в разделе 4. Заголовки расширений IPv6.
    

    Erratum ID 2843 — это сообщение отвергнуто (Rejected) и никаких изменений не внесено.
    

    • 



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


Авторы выражают свою признательность за многочисленные предложения членам рабочей группы Ipng, исследовательской группы End-to-End Protocols и всему сообществу Internet.


Авторы также признательным авторам обновлённых RFC, которые были включены в этот документ для получения спецификацией IPv6 статуса Internet Standard. Это Joe Abley, Shane Amante, Jari Arkko, Manav Bhatia, Ronald P. Bonica, Scott Bradner, Brian Carpenter, P.F. Chimento, Marshall Eubanks, Fernando Gont, James Hoagland, Sheng Jiang, Erik Kline, Suresh Krishnan, Vishwas Manral, George Neville-Neil, Jarno Rajahalme, Pekka Savola, Magnus Westerlund и James Woodyatt.


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


Stephen E. Deering


Retired


Vancouver, British Columbia


Canada


Robert M. Hinden


Check Point Software


959 Skyway Road


San Carlos, CA 94070


United States of America


Email: bob.hinden@gmail.com




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


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


nmalykh@protokols.ru




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






2Для опций, которые будут обрабатываться первым получателем, указанным в поле IPv6 Destination Address, плюс получатели, указанные далее в заголовке Routing.






3Дополнительные требования к относительному порядку заголовков Authentication и Encapsulating Security Payload приведены в [RFC4303].






4Для опций, обрабатываемых только адресатом пакета.






5Type-length-value — тип, размер, значение.






6Формат опции Pad1 отличается от обычного TLV, опция не включает полей размера и значения.






7В отличие от IPv4 фрагментация в IPv6 выполняется только отправителями, а не маршрутизаторами на пути доставки (5. Размер пакетов).






8«Недавно» означает «в пределах максимального вероятного времени жизни пакета, включая время передачи от отправителя к получателю и время ожидания сборки фрагментов». Однако узел-источник не обязан знать максимальное время жизни пакета. Вместо этого предполагается, что требование может быть удовлетворено за счёт использования алгоритма, обеспечивающего низкую частоту повторного использования значений. Примеры таких алгоритмов описаны в [RFC7739].






9Encapsulating Security Payload — инкапсуляция защищённых данных.






10Это ограничивает размер заголовков (с учётом заголовка Upper-Layer) величиной MTU на пути к адресатам.






11Максимальный размер сегмента TCP.






12Man-in-the-middle — перехват и изменение пакетов с участием человека.






13Denial-of-service — атака, нацеленная на отказ в обслуживании.






14Transport Layer Security — защита на транспортном уровне.






15Secure Shell.






16Authentication Header — заголовок аутентификации.





 							

	
			

									
						Рубрика: RFC					
					|
				
				
				Комментарии к записи RFC 8200 Internet Protocol, Version 6 (IPv6) Specification отключены

							

		


		
	

	
			

			
RFC 8203 BGP Administrative Shutdown Communication


			

				Опубликовано 11.07.2017 автором Nikolai Malykh			


					

				
Internet Engineering Task Force (IETF)                       J. Snijders
Request for Comments: 8203                                           NTT
Updates: 4486                                                   J. Heitz
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                               J. Scudder
                                                                 Juniper
                                                               July 2017




Сообщения BGP Shutdown




BGP Administrative Shutdown Communication


PDF


Аннотация


Этот документ дополняет субкоды Administrative Shutdown и Administrative Reset сообщений BGP Cease NOTIFICATION для операторов с целью передачи коротких сообщений в свободном формате для описания причин сброса или разрыва сессий BGP. Документ служит обновлением RFC 4486.


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


Документ относится к категории Internet Standards Track.


Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).


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


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


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


К документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).


1. Введение


Для оператора может оказаться сложным сопоставление разрыва сессии BGP-4 [RFC4271] в сети с уведомлением, переданным по отдельному «каналу» (например, по электронной почте или телефону). Этот документ обновляет [RFC4486] путем задания механизма передачи короткого сообщения в кодировке UTF-8 [RFC3629] со свободным форматом в составе сообщений Cease NOTIFICATION [RFC4271] для информирования партнера о причине разрыва сессии BGP.


1.1. Уровни требования


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


2. Поле Shutdown Communication


Если узел BGP решает разорвать сессию со своим BGP-соседом и передает сообщение NOTIFICATION с кодом ошибки (Error Code) Cease и субкодом (Error Subcode) Administrative Shutdown или Administrative Reset [RFC4486], он может включить в сообщение строку в кодировке UTF-8. Содержимое этой строки оператор определяет самостоятельно.


Формат сообщения Cease NOTIFICATION с полем Shutdown Communication показан ниже.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code 6  |    Subcode    |    Length     |     ...       \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
\                                                               \
/                 ... Shutdown Communication ...                /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Рисунок 1


Subcode


Значение Error Subcode должно быть 2 (Administrative Shutdown) или 4 (Administrative Reset).


Length


8-битовое поле, представляющее размер строки Shutdown Communication в октетах. Поле размера может принимать значение от 0 до 128 включительно. Нулевое размер говорит об отсутствии поля Shutdown Communication.


Shutdown Communication


Для поддержки разных языков поле Shutdown Communication должно представляться в кодировке UTF-8. Принимающему узлу BGP недопустимо интерпретировать неприемлемые последовательности UTF-8. Отметим, что при включении в Shutdown Communication символов, представляемых не одним байтом, число символов строки будет меньше значения поля Length. NUL-символ в конце строки не используется.


Механизмы передачи операторам информации из Shutdown Communication зависят от реализации, но следует включать в число таких механизмов запись в Syslog [RFC5424].


3. Практическое применение


Операторам настоятельно рекомендуется использовать Shutdown Communication для информирования своих партнеров о причинах разрыва сессий BGP и включать в сообщения ссылки на связанные с этими событиями материалы. Ниже приведены два примера полезных сообщений Shutdown Communication.


«[TICKET-1-1438367390] обновление программ; восстановление в течение 2 часов»


«[TICKET-1-1438367390]» представляет собой ссылку на «квитанцию», которая имеет понятна обеим сторонам, за которой следует краткое и понятное человеку сообщение о причине разрыва сессии BGP с информацией о продолжительности срока обслуживания. Получатель может воспользоваться строкой TICKET-1-1438367390 для поиска более подробной информации в своем архиве электронной почты.


4. Обработка ошибок


Если поле Shutdown Communication имеет некорректный размер или неверную последовательность символов UTF-8, в системный журнал от этом следует уведомить оператора. Можно в таких случаях также записывать в системный журнал шестнадцатеричный дамп всего поля Shutdown Communication.


5. Взаимодействие с IANA


IANA указывает этот документ (в дополнение к [RFC4486]) для субкодов Administrative Shutdown (2) и Administrative Reset (4) в реестре Cease NOTIFICATION message subcodes для группы параметров Border Gateway Protocol (BGP) Parameters.


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


Этот документ указывает использование кодировки UTF-8 для Shutdown Communication. С кодировкой Unicode связано множество проблем безопасности. Разработчикам и операторам рекомендуется прочесть отчет Unicode Technical Report #36 [UTR36] для получения информации об этих проблемах. Требуется применять UTF-8 Shortest Form для защиты от технических проблем, указанных в [UTR36].


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


Пользователям этого механизма следует принимать во внимание, что при отсутствии на транспортном уровне защиты целостности для сеансов BGP сообщения Shutdown Communication можно подделать. Если транспортный уровень не обеспечивает защиту конфиденциальности, злоумышленник может создавать обманные сообщения Shutdown Communication. Эта проблема относится ко всем сообщениям BGP, но может вызывать повышенный интерес в контексте данного предложения, поскольку передаваемая в сообщениях информация обычно предназначена для прочтения людьми. Аналогичные вопросы рассмотрены в [RFC4271] и [RFC4272].


Пользователям этого механизма следует рассмотреть вопрос минимизации передаваемых в сообщениях данных, как описано в параграфе 6.1 [RFC6973], поскольку принятые сообщения Shutdown Communication могут использоваться по усмотрению получателя.


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


7.1. Нормативные документы


[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.


[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.


[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.


[RFC4486] Chen, E. and V. Gillet, «Subcodes for BGP Cease Notification Message», RFC 4486, DOI 10.17487/RFC4486, April 2006, <http://www.rfc-editor.org/info/rfc4486>.


[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.


7.2. Дополнительная литература


[RFC4272] Murphy, S., «BGP Security Vulnerabilities Analysis», RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.


[RFC5424] Gerhards, R., «The Syslog Protocol», RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.


[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, «Privacy Considerations for Internet Protocols», RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.


[UTR36] Davis, M., Ed. and M. Suignard, Ed., «Unicode Security Considerations», Unicode Technical Report #36, August 2010, <http://unicode.org/reports/tr36/>.


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


Авторы выражают свою признательность Tom Scholl, David Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, Saku Ytti, Lou Berger, Alvaro Retana и Adam Roach.


Авторы благодарят Enke Chen и Vincent Gillet за их работу [RFC4486] и предоставление относящихся к ней прав IETF Trust в соответствии с BCP 78.


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


Job Snijders


NTT Communications


Theodorus Majofskistraat 100


Amsterdam 1065 SZ


The Netherlands


Email: job@ntt.net


Jakob Heitz


Cisco


170 West Tasman Drive


San Jose, CA 95134


United States of America


Email: jheitz@cisco.com


John Scudder


Juniper Networks


1194 N. Mathilda Ave


Sunnyvale, CA 94089


United States of America


Email: jgs@juniper.net


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


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


nmalykh@gmail.com 




1Internet Engineering Task Force.






2Internet Engineering Steering Group.






3Полужирными в переводах. Прим. перев.




 							

	
			

									
						Рубрика: RFC					
					|
				
				
				Комментарии к записи RFC 8203 BGP Administrative Shutdown Communication отключены

							

		


		
	

	
			

			
RFC 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies


			

				Опубликовано 04.07.2017 автором Nikolai Malykh			


					

				
Internet Engineering Task Force (IETF)                          J. Mauch
Request for Comments: 8212                                        Akamai
Updates: 4271                                                J. Snijders
Category: Standards Track                                            NTT
ISSN: 2070-1721                                               G. Hankins
                                                                   Nokia
                                                               July 2017



Распространение маршрутов EBGP без политики


Default External BGP (EBGP) Route Propagation Behavior without Policies


PDF


Аннотация


Этот документ обновляет RFC 4271, определяя принятое по умолчанию поведение поведение узлов BGP при отсутствии политики импорта или экспорта, связанной с сессией External BGP.


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


Документ относится к категории Internet Standards Track.


Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).


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


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


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


К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).


1. Введение


Для обеспечения более стабильной работы Internet требуется решить вопросы защиты маршрутизации BGP. Утечки маршрутов [RFC7908] являются частью этой проблемы, но в нее могут вносить свой вклад дефекты программ и ошибки операторов. Данный документ обновляет [RFC4271] так, что экспорта и импорта маршрутов не происходит, пока это не будет явно разрешено в конфигурации. Это смягчает последствия упомянутой проблемы и повышает устанавливаемый по умолчанию уровень безопасности маршрутизации Internet.


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


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


Узлы BGP, соответствующие данной спецификации не используют и не передают маршрутов в сессии EBGP, пока это явно не задано в конфигурации.


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


В [RFC4271] описана информационная база правил (PIB3), содержащая локальные правила, применяемые к информации из базы маршрутных данных RIB4. Данный документ разделяет типы правил (политики) на основе их применения.


Политика импорт — локальные правила, применяемые к информации, содержащейся в Adj-RIBs-In. Как описано в параграфе 3.2 [RFC4271], Adj-RIBs-In содержит информацию, полученную от других узлов BGP и применение этой политики дает в результате маршруты, которые будут учитываться в процессе принятия решений (Decision Process) данным узлом BGP.


Политика экспорта применяется при выборе информации, содержащейся в Adj-RIBs-Out. Как указано в параграфе 3.2 [RFC4271], Adj-RIBs-Out содержит информацию, выбранную для анонсирования другим узлам BGP.


2.1. Уровни требований


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


3. Отличия от RFC 4271


Этот раздел обновляет [RFC4271] с целью указания конкретного поведения узлов BGP при отсутствии правил импорта или экспорта, связанных с конкретной сессией EBGP. Узел BGP может поддерживать конфигурационные параметры, обеспечивающие отличное от описанного ниже поведение.


Приведенный ниже абзац добавляется в параграф 9.1 «Процесс выбора маршрутов (Decision Process)» после пятого абзаца, который заканчивается словами «объединение маршрутов и снижение объема маршрутной информации»5.


Маршруты из Adj-RIB-In, связанные с данным партнером EBGP, не следует рассматривать, как желательные (eligible) в Decision Process, если к ним не была явно применена политика импорта (Import Policy).


Приведенный ниже абзац добавляется в параграф 9.1.3 «Фаза 3: Распространение маршрутов (Route Dissemination)» после третьего абзаца, который заканчивается словами «с помощью сообщения UPDATE (см. параграф 9.2)».


Маршруты не следует добавлять в Adj-RIB-Out, связанную с данным партнером EBGP, если к ним не была явно применена политика экспорта.


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


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


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


Вопросы безопасности, рассмотренные в [RFC4271], и анализ уязвимостей в [RFC4272] применимы и к данному документу.


5. Взаимодействие с IANA


Этот документ не требует каких-либо действий IANA.


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


6.1. Нормативные документы


[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.


[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.


[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.


6.2. Дополнительная литература


[RFC4272] Murphy, S., «BGP Security Vulnerabilities Analysis», RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.


[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, «Problem Definition and Classification of BGP Route Leaks», RFC 7908, DOI 10.17487/RFC7908, June 2016, <http://www.rfc-editor.org/info/rfc7908>.


Приложение A. Вопросы перехода для разработчиков BGP


Это приложение не является нормативным.


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


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


A.1. Стратегия N+1 N+2


Разработчики могут использовать модель, описанную, как стратегия выпуска «N+1 и N+2». В выпуске N+1 вводятся новые конфигурационные параметры, используемые по умолчанию для индикации работы узла BGP в небезопасном режиме (ebgp insecure-mode). Кроме добавление нового параметра разработчики могут добавить выдачу оператору предупреждений о том, что в некоторых частях конфигурация не полна. В выпуске N+1 операторы такой реализации BGP будут знать, что имеется возможность настройки конфигурации и могут соответствующим образом ее сделать. В выпуске N+2 или позднее может быть введен используемый по умолчанию параметр, с обратным по отношение к N+1 смыслом.


В результате новые инсталляции выпуска N+2 будут соответствовать данному документу. Инсталляции выпуска N+1 будут следовать прежнему, незащищенному поведению, если конфигурационный параметр ebgp insecure-mode не будет изменен.


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


Авторы благодарны за рецензии, комментарии и поддержку Shane Amante, Christopher Morrow, Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald Smith, Alvaro Retana, John Scudder и Dale Worley.


Участники


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


Jakob Heitz

 Cisco

Email: jheitz@cisco.com


Ondrej Filip

 CZ.NIC

Email: ondrej.filip@nic.cz


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


Jared Mauch

 Akamai Technologies

8285 Reese Lane

Ann Arbor Michigan 48103

United States of America

Email: jared@akamai.com


Job Snijders

 NTT Communications

Theodorus Majofskistraat 100

Amsterdam 1065 SZ

The Netherlands

Email: job@ntt.net


Greg Hankins

 Nokia

777 E. Middlefield Road

Mountain View, CA 94043

United States of America

Email: greg.hankins@nokia.com




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

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

nmalykh@gmail.com 




1Internet Engineering Task Force.






2Internet Engineering Steering Group.






3Policy Information Base.






4Routing Information Base — база данных о маршрутизации.






5Это последний абзац параграфа, п c). Прим. перев.




 							

	
			

									
						Рубрика: RFC					
					|
				
				
				Комментарии к записи RFC 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies отключены

							

		


		
	

	
			

			
RFC 8177 YANG Data Model for Key Chains


			

				Опубликовано 28.06.2017 автором Nikolai Malykh			


					

				
Internet Engineering Task Force (IETF)                    A. Lindem, Ed.
Request for Comments: 8177                                 Cisco Systems
Category: Standards Track                                          Y. Qu
ISSN: 2070-1721                                                   Huawei
                                                                D. Yeung
                                                             Arrcus, Inc
                                                                 I. Chen
                                                                   Jabil
                                                                J. Zhang
                                                        Juniper Networks
                                                               June 2017



YANG Data Model for Key Chains


Модель данных YANG для цепочек ключей


PDF


Аннотация


Этот документ описывает модель данных YANG для цепочек ключей. Такие цепочки широко применяются для аутентификации протоколов маршрутизации и в других приложениях, требующих симметричных ключей. Цепочка ключей — это список из одного или нескольких элементов, содержащих Key ID, строку ключа, сроки действия для отправки и восприятия, связанный алгоритм проверки подлинности и шифрования. За счёт подобающего перекрытия сроков действия для отправки и восприятия нескольких элементов цепочки ключей строки ключей и алгоритмы можно аккуратно обновлять. Представление в модели данных YANG позволяет автоматизировать распространение ключей.


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


Документ относится к категории Internet Standards Track.


Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.


Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc8177.


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


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


К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).


1. Введение


Этот документ описывает модель данных YANG [YANG-1.1] для цепочек ключей. Цепочки широко применяются для аутентификации в протоколах маршрутизации, а также в других приложениях, которым нужны симметричные ключи. Цепочка ключей — это список из одного или нескольких элементов, содержащих Key ID, строку ключа, сроки действия для отправки и восприятия, связанный алгоритм проверки подлинности и шифрования. За счёт подобающего перекрытия сроков действия для отправки и восприятия нескольких элементов цепочки ключей строки ключей и алгоритмы можно аккуратно обновлять. Представление в модели данных YANG позволяет автоматизировать распространение ключей.


В некоторых приложениях протоколы не используют напрямую элементы цепочки ключей, а применяют функцию вывода ключей для создания краткосрочного ключа из элементов цепочки (например, первичные ключи в [TCP-AO]).


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


Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [KEYWORDS] [KEYWORDS-UPD] тогда и только тогда, когда они выделены шрифтом, как показано здесь.


1.2. Диаграммы деревьев


Упрощённое графическое представление полного дерева данных дано в параграфе 3.3 с использованием приведённых ниже обозначений.


    

  • 

    Квадратные скобки [ и ] содержат в себе ключи. Их не следует путать с ключами цепочек.
    

    • 

  • 

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

    • 

  • 

    В сокращениях перед именами узлов rw указывает данные конфигурации (read-write), ro — данные состояния (read-only), -x — операции RPC или действия, -n — уведомления.
    

    • 

  • 

    После имени узла символ ? Указывает необязательный узел, ! — контейнер с присутствием, * — list или leaf-list.
    

    • 

  • 

    Круглые скобки включают узлы choice и case, а узлы case помечаются также двоеточием (:).
    

    • 

  • 

    Три точки (…) указывают пропущенное содержимое субдерева (ветви).
    

    • 



2. Постановка задачи


Этот документ описывает модель данных YANG [YANG-1.1] для цепочек ключей. Цепочки ключей реализованы и развёрнуты большинством производителей сетевого оборудования. Создание стандартной модели YANG будет способствовать автоматическому распространению ключей и их неразрушающей смене (rollover). Это поможет улучшить защищенность инфраструктуры ядра маршрутизации в соответствии с рекомендациями [IAB-REPORT].


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


Концептуальное представление таблицы криптоключей описано в [CRYPTO-KEYTABLE]. Таблица включает ключи со сроками их действия и алгоритмами. Кроме того, в таблицу включается критерий выбора и она предназначена для модели развёртывания, где сведения о приложениях и службах, требующих аутентификации или шифрования, проникают в базу данных о ключах. Модель YANG для цепочки ключей, описанная здесь, не включает критериев выбора и не поддерживает эту модель развёртывания. Однако модель и не исключает этого. В [YANG-CRYPTO-KEYTABLE] описаны дополнения к модели YANG для цепочки ключей в поддержку критериев выбора.


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


Другие модули YANG могут ссылаться на имена цепочек в модуле YANG ietf-key-chain для приложений аутентификации и шифрования. Предоставлен тип YANG для упрощения ссылок на имя цепочки ключей без указания полного выражения YANG XPath3.


2.2. Аккуратная смена ключей с использованием цепочек


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


    

  1. 

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

    2. 

  2. 

    Проверяется получение новой цепочки всеми сетевыми устройствами и примерная синхронизация их часов. Системные часы устройств в административном домене обычно синхронизированы, например, по протоколу сетевого времени (Network Time Protocol или NTP) [NTP-PROTO]). Эту процедуру можно автоматизировать.
    

    3. 

  3. 

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

    4. 

  4. 

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

    5. 



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


3. Устройство модели для цепочек ключей


Модуль ietf-key-chain содержит список из одного или нескольких ключей с индексом Key ID. Для некоторых приложений (например, OSPFv3 [OSPFV3-AUTH]) Key ID применяется для указания используемой цепочки ключей. Кроме Key ID каждый ключ включает строку ключа и криптографический алгоритм, а также может включать срок действия для передачи и восприятия ключа (по умолчанию ключи действительны всегда).


Отметим, что разные сроки действия для передачи и восприятия могут указываться в разных элементах. Ключ для передачи может иметь действительное значение send-lifetime и непригодное значение accept-lifetime (например, end-time = start-time). Ключ, применяемый для восприятия может иметь действительное значение accept-lifetime и непригодное значение send-lifetime.


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


Цепочка ключей указывается уникальным в масштабе сетевого устройства именем. Другим модулям следует применять определение типа (typedef) из key-chain-ref при необходимости указать настроенную цепочку ключей.


3.1. Рабочее состояние цепочки ключей


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


3.2. Свойства модели


Для обработки различий между реализациями разных производителей используются операторы feature. Например, не все производители поддерживают настройку допустимого отклонения при восприятии или шестнадцатеричные строки для ключей. Свойства (feature) также применяются для поддержки требований безопасности (например, алгоритмов TCP-AO [TCP-AO-ALGORITHMS]), ещё не реализованных производителями или реализованных только одним из них.


Обычно элемент с достаточными правами может читать и сохранять конфигурацию устройства, включающую содержимое этой модели. Для предотвращения ненужного просмотра и хранения ключей в открытом виде (cleartext) модель поддерживает функцию (feature) aes-key-wrap (см. 5. Вопросы безопасности).


3.3. Дерево модели для цепочки ключей


   +--rw key-chains
      +--rw key-chain* [name]
      |  +--rw name                       string
      |  +--rw description?               string
      |  +--rw accept-tolerance {accept-tolerance}?
      |  |  +--rw duration?   uint32
      |  +--ro last-modified-timestamp?   yang:date-and-time
      |  +--rw key* [key-id]
      |     +--rw key-id                    uint64
      |     +--rw lifetime
      |     |  +--rw (lifetime)?
      |     |     +--:(send-and-accept-lifetime)
      |     |     |  +--rw send-accept-lifetime
      |     |     |     +--rw (lifetime)?
      |     |     |        +--:(always)
      |     |     |        |  +--rw always?            empty
      |     |     |        +--:(start-end-time)
      |     |     |           +--rw start-date-time?
      |     |     |           |       yang:date-and-time
      |     |     |           +--rw (end-time)?
      |     |     |              +--:(infinite)
      |     |     |              |  +--rw no-end-time?       empty
      |     |     |              +--:(duration)
      |     |     |              |  +--rw duration?          uint32
      |     |     |              +--:(end-date-time)
      |     |     |                 +--rw end-date-time?
      |     |     |                         yang:date-and-time
      |     |     +--:(independent-send-accept-lifetime)
      |     |        |   {independent-send-accept-lifetime}?
      |     |        +--rw send-lifetime
      |     |        |  +--rw (lifetime)?
      |     |        |     +--:(always)
      |     |        |     |  +--rw always?            empty
      |     |        |     +--:(start-end-time)
      |     |        |        +--rw start-date-time?
      |     |        |        |       yang:date-and-time
      |     |        |        +--rw (end-time)?
      |     |        |           +--:(infinite)
      |     |        |           |  +--rw no-end-time?       empty
      |     |        |           +--:(duration)
      |     |        |           |  +--rw duration?          uint32
      |     |        |           +--:(end-date-time)
      |     |        |              +--rw end-date-time?
      |     |        |                      yang:date-and-time
      |     |        +--rw accept-lifetime
      |     |           +--rw (lifetime)?
      |     |              +--:(always)
      |     |              |  +--rw always?            empty
      |     |              +--:(start-end-time)
      |     |                 +--rw start-date-time?
      |     |                 |       yang:date-and-time
      |     |                 +--rw (end-time)?
      |     |                    +--:(infinite)
      |     |                    |  +--rw no-end-time?       empty
      |     |                    +--:(duration)
      |     |                    |  +--rw duration?          uint32
      |     |                    +--:(end-date-time)
      |     |                       +--rw end-date-time?
      |     |                               yang:date-and-time
      |     +--rw crypto-algorithm identityref
      |     +--rw key-string
      |     |  +--rw (key-string-style)?
      |     |     +--:(keystring)
      |     |     |  +--rw keystring?            string
      |     |     +--:(hexadecimal) {hex-key-string}?
      |     |        +--rw hexadecimal-string?   yang:hex-string
      |     +--ro send-lifetime-active?     boolean
      |     +--ro accept-lifetime-active?   boolean
      +--rw aes-key-wrap {aes-key-wrap}?
         +--rw enable?   boolean


4. Модель YANG Key Chain


   <CODE BEGINS> file "ietf-key-chain@2017-06-15.yang"
   module ietf-key-chain {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain";
     prefix key-chain;

     import ietf-yang-types {
       prefix yang;
     }
     import ietf-netconf-acm {
       prefix nacm;
     }

     organization
       "IETF RTGWG - Routing Area Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/group/rtgwg> 
        WG List:  <mailto:rtgwg@ietf.org> 

        Editor: Acee Lindem
                <mailto:acee@cisco.com> 
                Yingzhen Qu
                <mailto:yingzhen.qu@huawei.com> 
                Derek Yeung
                <mailto:derek@arrcus.com> 
                Ing-Wher Chen
                <mailto:Ing-Wher_Chen@jabail.com> 
                Jeffrey Zhang
                <mailto:zzhang@juniper.net>"; 

     description
       "Этот модуль YANG задаёт базовые данные конфигурации для
        цепочек ключей. Предполагается, что производители будут
        расширять модуль своими параметрами цепочек ключей.

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

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 8177, где правовые
        аспекты приведены более полно.";

     reference "RFC 8177";

     revision 2017-06-15 {
       description
         "Исходный выпуск RFC";
       reference "RFC 8177: YANG Data Model for Key Chains";
     }

     feature hex-key-string {
       description
         "Поддержка шестнадцатеричных строк для ключей.";
     }

     feature accept-tolerance {
       description
         "Поддержка допуска или предела для восприятия.";
     }

     feature independent-send-accept-lifetime {
       description
         "Поддержка независимых сроков действия для передачи 
          и восприятия.";
     }

     feature crypto-hmac-sha-1-12 {
       description
         "Поддержка 12-байтовых дайджестов TCP HMAC-SHA-1.";
     }

     feature cleartext {
       description
         "Поддержка алгоритма cleartext (НЕ РЕКОМЕНДУЕТСЯ).";
     }

     feature aes-cmac-prf-128 {
       description
         "Поддержка псевдослучайной функции AES Cipher-based MAC.";
     }

     feature aes-key-wrap {
       description
         "Поддержка AES Key Wrap.";
     }

     feature replay-protection-only {
       description
         "Обеспечивает защиту от повторного использования без
          аутентификации, требуемую такими протоколами как BFD.";
     }
     identity crypto-algorithm {
       description
         "Базовое отождествление опций криптографического алгоритма.";
     }

     identity hmac-sha-1-12 {
       base crypto-algorithm;
       if-feature "crypto-hmac-sha-1-12";
       description
         "Алгоритм HMAC-SHA1-12.";
     }

     identity aes-cmac-prf-128 {
       base crypto-algorithm;
       if-feature "aes-cmac-prf-128";
       description
         "Алгоритм AES-CMAC-PRF-128. Требуется RFC 5926 для функций 
          вывода ключей TCP-AO.";
     }

     identity md5 {
       base crypto-algorithm;
       description
         "Алгоритм MD5.";
     }

     identity sha-1 {
       base crypto-algorithm;
       description
         "Алгоритм SHA-1.";
     }

     identity hmac-sha-1 {
       base crypto-algorithm;
       description
         "Алгоритм аутентификации HMAC-SHA-1.";
     }

     identity hmac-sha-256 {
       base crypto-algorithm;
       description
         "Алгоритм аутентификации HMAC-SHA-256.";
     }

     identity hmac-sha-384 {
       base crypto-algorithm;
       description
         "Алгоритм аутентификации HMAC-SHA-384.";
     }

     identity hmac-sha-512 {
       base crypto-algorithm;
       description
         "Алгоритм аутентификации HMAC-SHA-512.";
     }

     identity cleartext {
       base crypto-algorithm;
       if-feature "cleartext";
       description
         "Открытый текст (cleartext).";
     }

     identity replay-protection-only {
       base crypto-algorithm;
       if-feature "replay-protection-only";
       description
         "Обеспечивает защиту от повторного использования без
          аутентификации, требуемую такими протоколами как BFD.";
     }

     typedef key-chain-ref {
       type leafref {
         path
         "/key-chain:key-chains/key-chain:key-chain/key-chain:name";
       }
       description
         "Применяется моделями данных для ссылки на настроенные 
          цепочки ключей.";
     }

     grouping lifetime {
       description
         "Key lifetime specification.";
       choice lifetime {
         default "always";
         description
           "Опции задания срока действия для передачи и восприятия";
         case always {
           leaf always {
             type empty;
             description
               "Ключ действителен всегда.";
           }
         }
         case start-end-time {
           leaf start-date-time {
             type yang:date-and-time;
             description
               "Время начала.";
           }
           choice end-time {
             default "infinite";
             description
               "Время окончания для передачи.";
             case infinite {
               leaf no-end-time {
                 type empty;
                 description
                   "Время завершения срока действия не ограничено.";
               }
             }
             case duration {
               leaf duration {
                 type uint32 {
                   range "1..2147483646";
                 }
                 units "seconds";
                 description
                   "Срок действия ключа в секундах.";
               }
             }
             case end-date-time {
               leaf end-date-time {
                 type yang:date-and-time;
                 description
                   "Время завершения.";
               }
             }
           }
         }
       }
     }

     container key-chains {
       description
         "Все настроенные цепочки ключей имеются на устройстве.";
       list key-chain {
         key "name";
         description
           "Список цепочек ключей.";
         leaf name {
           type string;
           description
             "Имя цепочки ключей.";
         }
         leaf description {
           type string;
           description
             "Описание цепочки ключей.";
         }
         container accept-tolerance {
           if-feature "accept-tolerance";
           description
             "Отклонение для срока действия при восприятии (секунды).";
           leaf duration {
             type uint32;
             units "seconds";
             default "0";
             description
               "Диапазон отклонения в секундах.";
           }
         }
         leaf last-modified-timestamp {
           type yang:date-and-time;
           config false;
           description
             "Временная сетка последнего обновления цепочки ключей.";
         }
         list key {
           key "key-id";
           description
             "Один ключ в цепочке.";
           leaf key-id {
             type uint64;
             description
               "Уникальный числовой идентификатор ключа.";
           }
           container lifetime {
             description
               "Срок действия ключа.";
             choice lifetime {
               description
                 "Варианты задания срока действия при передаче 
                  и восприятии.";
               case send-and-accept-lifetime {
                 description
                   "Сроки действия передачи и восприятия одинаковы.";
                 container send-accept-lifetime {
                   description
                     "Одно значение срока для восприятия и передачи.";
                   uses lifetime;
                 }
               }
               case independent-send-accept-lifetime {
                 if-feature "independent-send-accept-lifetime";
                 description
                   "Независимые сроки действия восприятия и передачи.";
                 container send-lifetime {
                   description
                     "Отдельный срок действия для передачи.";
                   uses lifetime;
                 }
                 container accept-lifetime {
                   description
                     "Отдельный срок действия для восприятия.";
                   uses lifetime;
                 }
               }
             }
           }
           leaf crypto-algorithm {
             type identityref {
               base crypto-algorithm;
             }
             mandatory true;
             description
               "Криптоалгоритм, связанный с ключом.";
           }
           container key-string {
             description
               "The key string.";
             nacm:default-deny-all;
             choice key-string-style {
               description
                 "Стили строк ключей";
                case keystring {
                  leaf keystring {
                   type string;
                   description
                     "Строка ключа в формате ASCII.";
                 }
               }
               case hexadecimal {
                 if-feature "hex-key-string";
                 leaf hexadecimal-string {
                   type yang:hex-string;
                   description
                     "Ключ в форме шестнадцатеричной строки. По сравнению
                      обеспечивает большую энтропию при том же числе 
                      октетов в строке. Кроме того, препятствует применению
                      общеизвестных слов и чисел.";
                 }
               }
             }
           }
           leaf send-lifetime-active {
             type boolean;
             config false;
             description
               "Срок действия передачи для ключа активной цепочки.";
              }
           leaf accept-lifetime-active {
             type boolean;
             config false;
             description
               "Срок действия восприятия для ключа активной цепочки.";
           }
         }
       }
       container aes-key-wrap {
         if-feature "aes-key-wrap";
         description
           "Шифрование AES Key Wrap для строк ключей. Строки кодируются
            в шестнадцатеричной форме с применением листа
            hex-key-string.";
         leaf enable {
           type boolean;
           default "false";
           description
             "Включает шифрование AES Key Wrap.";
         }
       }
     }
   }
   <CODE ENDS>


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


Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [NETCONF] или RESTCONF [RESTCONF]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [NETCONF-SSH]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [TLS].


Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [NETCONF-ACM] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого. Строки ключей по умолчанию недоступны и требуются правила доступа NETCONF [NETCONF-ACM] для их настройки или извлечения.


Строки ключей могут зашифрованы с использованием алгоритма AES Key Wrap [AES-KEY-WRAP]. Ключ шифрования ключей AES (key-encryption key или KEK) не включён в модель YANG и должен задаваться или выводиться независимо от конфигурации цепочки ключей. При использовании шифрования AES требуется также свойство hex-key-string, поскольку зашифрованные ключи будут содержать символы, которые невозможно представить встроенным типом YANG string [YANG-1.1]. Рекомендуется шифровать строки ключей с помощью ключа шифрования AES для предотвращение извлечения и сохранения строк ключей в открытом виде. Эта рекомендация не зависит от защиты доступа, обеспечиваемой моделью NACM [NETCONF-ACM].


В свойства (feature) модели YANG включён алгоритм cleartext. Его использование не рекомендуется за исключением случаев, когда у устройства и приложения нет иных вариантов (например, унаследованное сетевое устройство, которое должно аутентифицировать пакеты с интервалом 10 мсек или меньше для множества партнёров BFD [BFD]). Ключи, применяемые с алгоритмом cleartext, считаются незащищённые и такой ключ не следует применять в тоже время для более защищённого алгоритма.


Алгоритмы MD5 и SHA-1 тоже сочтены небезопасными ([Dobb96a], [Dobb96b], [SHA-SEC-CON]) и применять из не рекомендуется. Следует ограничивать их использование развёртываниями, где нужна совместимость с прежними версиями.


Реализациям, с ключами, предоставляемыми с помощью этой модели, следует хранить ключи с использованием имеющегося опыта защиты (best current security practice).


6. Взаимодействие с IANA


Этот документ регистрирует URI в реестре IETF XML Registry» [XML-REGISTRY] в формате [XML-REGISTRY].


      URI: urn:ietf:params:xml:ns:yang:ietf-key-chain
      Registrant Contact: The IESG.
      XML: N/A, запрашиваемый URI является пространством имён XML.


Этот документ регистрирует модуль YANG в реестре YANG Module Names [YANG-1.0].


      name: ietf-key-chain
      namespace: urn:ietf:params:xml:ns:yang:ietf-key-chain
      prefix: key-chain
      reference: RFC 8177


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


7.1. Нормативные документы


[KEYWORDS] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.


[KEYWORDS-UPD] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.


[NETCONF] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.


[NETCONF-ACM] Bierman, A. and M. Bjorklund, «Network Configuration Protocol (NETCONF) Access Control Model», RFC 6536, DOI 10.17487/RFC6536, March 2012, <http://www.rfc-editor.org/info/rfc6536>.


[NETCONF-SSH] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, DOI 10.17487/RFC6242, June 2011, <http://www.rfc-editor.org/info/rfc6242>.


[RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <http://www.rfc-editor.org/info/rfc8040>.


[TLS] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.


[XML-REGISTRY] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.


[YANG-1.0] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.


[YANG-1.1] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <http://www.rfc-editor.org/info/rfc7950>.


7.2. Дополнительная литература


[AES-KEY-WRAP] Housley, R. and M. Dworkin, «Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm», RFC 5649, DOI 10.17487/RFC5649, September 2009, <http://www.rfc-editor.org/info/rfc5649>.


[BFD] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD)», RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.


[CRYPTO-KEYTABLE] Housley, R., Polk, T., Hartman, S., and D. Zhang, «Database of Long-Lived Symmetric Cryptographic Keys», RFC 7210, DOI 10.17487/RFC7210, April 2014, <http://www.rfc-editor.org/info/rfc7210>.


[Dobb96a] Dobbertin, H., «Cryptanalysis of MD5 Compress», Technical Report Presented at the Rump Session of EuroCrypt ’96, May 1996.


[Dobb96b] Dobbertin, H., «The Status of MD5 After a Recent Attack», CryptoBytes, Vol. 2, No. 2, Summer 1996.


[IAB-REPORT] Andersson, L., Davies, E., and L. Zhang, «Report from the IAB workshop on Unwanted Traffic March 9-10, 2006», RFC 4948, DOI 10.17487/RFC4948, August 2007, <http://www.rfc-editor.org/info/rfc4948>.


[NMDA] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture», Work in Progress4, draft-ietf-netmod-revised-datastores-02, May 2017.


[NTP-PROTO] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.


[OSPFV3-AUTH] Bhatia, M., Manral, V., and A. Lindem, «Supporting Authentication Trailer for OSPFv3», RFC 7166, DOI 10.17487/RFC7166, March 2014, <http://www.rfc-editor.org/info/rfc7166>.


[SHA-SEC-CON] Polk, T., Chen, L., Turner, S., and P. Hoffman, «Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms», RFC 6194, DOI 10.17487/RFC6194, March 2011, <http://www.rfc-editor.org/info/rfc6194>.


[TCP-AO] Touch, J., Mankin, A., and R. Bonica, «The TCP Authentication Option», RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.


[TCP-AO-ALGORITHMS] Lebovitz, G. and E. Rescorla, «Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)», RFC 5926, DOI 10.17487/RFC5926, June 2010, <http://www.rfc-editor.org/info/rfc5926>.


[YANG-CRYPTO-KEYTABLE] Chen, I., «YANG Data Model for RFC 7210 Key Table», Work in Progress, draft-chen-rtg-key-table-yang-00, March 2015.


Приложение A. Примеры


A.1. Простая цепочка с одним, всегда пригодным ключом


   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <key-chains xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">
       <key-chain>
         <name>keychain-no-end-time</name>
         <description>
           A key chain with a single key that is always valid for
           transmission and reception.
         </description>
         <key>
           <key-id>100</key-id>
           <lifetime>
             <send-accept-lifetime>
               <always/>
             </send-accept-lifetime>
           </lifetime>
           <crypto-algorithm>hmac-sha-256</crypto-algorithm>
           <key-string>
             <keystring>keystring_in_ascii_100</keystring>
           </key-string>
         </key>
       </key-chain>
     </key-chains>
   </data>


A.2. Цепочка ключей с разными сроками действия


   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <key-chains xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">
       <key-chain>
         <name>keychain2</name>
         <description>
           A key chain where each key contains a different send time
           and accept time and a different algorithm illustrating
           algorithm agility.
         </description>
         <key>
           <key-id>35</key-id>
           <lifetime>
             <send-lifetime>
               <start-date-time>2017-01-01T00:00:00Z</start-date-time>
               <end-date-time>2017-02-01T00:00:00Z</end-date-time>
             </send-lifetime>
             <accept-lifetime>
               <start-date-time>2016-12-31T23:59:55Z</start-date-time>
               <end-date-time>2017-02-01T00:00:05Z</end-date-time>
             </accept-lifetime>
           </lifetime>
           <crypto-algorithm>hmac-sha-256</crypto-algorithm>
           <key-string>
             <keystring>keystring_in_ascii_35</keystring>
           </key-string>
         </key>
         <key>
           <key-id>36</key-id>
           <lifetime>
             <send-lifetime>
               <start-date-time>2017-02-01T00:00:00Z</start-date-time>
               <end-date-time>2017-03-01T00:00:00Z</end-date-time>
             </send-lifetime>
             <accept-lifetime>
               <start-date-time>2017-01-31T23:59:55Z</start-date-time>
               <end-date-time>2017-03-01T00:00:05Z</end-date-time>
             </accept-lifetime>
           </lifetime>
           <crypto-algorithm>hmac-sha-512</crypto-algorithm>
           <key-string>
             <hexadecimal-string>fe:ed:be:af:36</hexadecimal-string>
           </key-string>
         </key>
       </key-chain>
     </key-chains>
   </data>


A.3. Цепочка с независимыми сроками для передачи и восприятия


   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <key-chains xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">
       <key-chain>
         <name>keychain2</name>
         <description>
           A key chain where each key contains different send times
           and accept times.
         </description>
         <key>
           <key-id>35</key-id>
           <lifetime>
             <send-lifetime>
               <start-date-time>2017-01-01T00:00:00Z</start-date-time>
               <end-date-time>2017-02-01T00:00:00Z</end-date-time>
             </send-lifetime>
             <accept-lifetime>
               <start-date-time>2016-12-31T23:59:55Z</start-date-time>
               <end-date-time>2017-02-01T00:00:05Z</end-date-time>
             </accept-lifetime>
           </lifetime>
           <crypto-algorithm>hmac-sha-256</crypto-algorithm>
           <key-string>
             <keystring>keystring_in_ascii_35</keystring>
           </key-string>
         </key>
         <key>
           <key-id>36</key-id>
           <lifetime>
             <send-lifetime>
               <start-date-time>2017-02-01T00:00:00Z</start-date-time>
               <end-date-time>2017-03-01T00:00:00Z</end-date-time>
             </send-lifetime>
             <accept-lifetime>
               <start-date-time>2017-01-31T23:59:55Z</start-date-time>
               <end-date-time>2017-03-01T00:00:05Z</end-date-time>
             </accept-lifetime>
           </lifetime>
           <crypto-algorithm>hmac-sha-256</crypto-algorithm>
           <key-string>
             <hexadecimal-string>fe:ed:be:af:36</hexadecimal-string>
           </key-string>
         </key>
       </key-chain>
     </key-chains>
   </data>


Участник работы


Yi Yang


SockRate


Email: yi.yang@sockrate.com


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


Спасибо Brian Weis за обсуждение вопросов безопасности.


Спасибо Ines Robles за комментарии к обзору Routing Directorate QA.


Спасибо Ladislav Lhotka за комментарии к обзору YANG Doctor.


Спасибо Martin Bjorklund за дополнительные комментарии к обзору YANG Doctor.


Спасибо Tom Petch за комментарии в IETF last call.


Спасибо Matthew Miller за комментарии при обзоре Gen-ART.


Спасибо Vincent Roca за комментарии при обзоре Security Directorate.


Спасибо Warren Kumari, Ben Campbell, Adam Roach, Benoit Claise за комментарии при обзоре IESG.


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




Acee Lindem (editor)


Cisco Systems


301 Midenhall Way


Cary, NC 27513


United States of America


Email: acee@cisco.com


 


Yingzhen Qu


Huawei


Email: yingzhen.qu@huawei.com


 


Derek Yeung


Arrcus, Inc


Email: derek@arrcus.com


 


Ing-Wher Chen


Jabil


Email: Ing-Wher_Chen@jabil.com


 


Jeffrey Zhang


Juniper Networks


10 Technology Park Drive


Westford, MA 01886


United States of America


Email: zzhang@juniper.net






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


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


nmalykh@protokols.ru 




1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.






2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.






3XML Path Language — язык путей XML.






4Опубликовано в RFC 8342. Прим. перев.



 							

	
			

									
						Рубрика: RFC					
					|
				
				
				Оставить комментарий

							

		


		
	

	
			

			
RFC 8190 Updates to the Special-Purpose IP Address Registries


			

				Опубликовано 17.06.2017 автором Nikolai Malykh			


					

				
Internet Engineering Task Force (IETF)                         R. Bonica
Request for Comments: 8190                              Juniper Networks
BCP: 153                                                       M. Cotton
Updates: 6890                                                        PTI
Category: Best Current Practice                              B. Haberman
ISSN: 2070-1721                                 Johns Hopkins University
                                                               L. Vegoda
                                                                   ICANN
                                                               June 2017




Updates to the Special-Purpose IP Address Registries


Обновление реестров адресов IP специального назначения


PDF


Аннотация


Этот документ обновляет реестры IANA для адресов специального назначения IPv4 и IPv6 путем введения определения «глобального» префикса. Документ также исправляет некоторые ошибки в записях реестрой для обеспечения целостности реестрой IANA для адресов специального назначения.


Документ обновляет RFC 6890.


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


Этот документ относится к категории «Обмен опытом» (Internet Best Current Practice).


Документ является результатом работы IETF1 и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG2. Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 7841.


Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc8190.


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


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


К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).


1. Введение


Для поддержки новых протоколов и практики IETF иногда резервирует блоки адресов специального назначения. Например, [RFC1122] резервирует блок адресов IPv4 (0.0.0.0/8) для представления местной (т. е. «данной») сети. Аналогично в [RFC4291] зарезервирован блок адресов IPv6 (fe80::/10) для представления индивидуальных адресов на канале.


Возникли некоторые вопросы с документированием отдельных блоков адресов специального назначения в [RFC6890]. В частности, определение global в [RFC6890] вводит в заблуждение, поскольку несколько отличается от общепринятого определения глобальной области действия (т. е. возможности пересылки за пределы административного домена, описанной как global unicast в архитектуре адресации [RFC4291]). Этот документ обновляет определение global, данное в [RFC6890] для реестров адресов специального назначения IPv4 и IPv6, дополняет поля реестров для устранения путаницы, связанной с определением global и исправляет некоторые ошибки в записях реестров адресов.


Документ обновляет [RFC6890].


2. Взаимодействие с IANA


2.1. Определение глобальной доступности


[RFC6890] определяет термин global без учета его применения в разных сферах. В частности, адрес IP может быть глобальным в смысле области действия, а также в смысле доступности и маршрутизации. Для устранения этой неоднозначности термин global, определенный в [RFC6890], заменен на globally reachable (глобально доступный). Ниже приведено определение, которое заменяет global в реестрах IANA для адресов специального назначения.


Globally Reachable — глобально доступный


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


В связи Destination с Forwardable и Global, описанной в [RFC6890], также указывается Globally Reachable. Если Destination = FALSE, значения Forwardable и Globally Reachable также должны быть FALSE.


Столбец Global в реестрах IPv4 Special-Purpose Address Registry (https://www.iana.org/assignments/iana-ipv4-special-registry) и IPv6 Special-Purpose Address Registry (https://www.iana.org/assignments/iana-ipv6-special-registry) переименован в Globally Reachable.


2.2. Обновление реестра IPv4 Special-Purpose Address Registry


    

  • 

    Для Limited Broadcast prefix (255.255.255.255/32) значение Reserved-by-Protocol сменено на True. Это было сделано для согласования реестра с выделением адреса ограниченного широковещания в разделе 7 [RFC919].
    

    • 



2.3. Обновления реестра IPv6 Special-Purpose Address Registry


Указанные ниже изменения реестра IPv6 Special-Purpose Address Registry включают добавление двух примечаний, ведущее к изменению нумерации имеющихся примечаний.


    

  • 

    Для префикса TEREDO (2001::/32) значение Globally Reachable было сменено с False на N/A [2]. Примечание [2] сейчас имеет вид:
    

    * See Section 5 of [RFC4380] for details3.
    

    • 

  • 

    Для EID Space for LISP (2001:5::/32) номера всех примечаний увеличились на 1.
    

    • 

  • 

    Для 6to4 (2002::/16) номера всех примечаний увеличились на 1.
    

    • 

  • 

    Для Unique-Local (fc00::/7) значение Globally Reachable (False) было сменено на False [7]. Примечание [7] имеет вид:
    

    * See [RFC4193] for more details on the routability of Unique-Local addresses. The Unique-Local prefix is drawn from the IPv6 Global Unicast Address range but is specified as not globally routed.4
    

    • 



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


Этот документ не создает проблем безопасности в дополнение к отмеченным в [RFC6890].


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


4.1. Нормативные документы


[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, «Special-Purpose IP Address Registries», BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.


4.2. Дополнительная литература


[RFC919] Mogul, J., «Broadcasting Internet Datagrams«, STD 5, RFC 919, DOI 10.17487/RFC0919, October 1984, <http://www.rfc-editor.org/info/rfc919>.


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


[RFC4193] Hinden, R. and B. Haberman, «Unique Local IPv6 Unicast Addresses», RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.


[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.


[RFC4380] Huitema, C., «Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)», RFC 4380, DOI 10.17487/RFC4380, February 2006, <http://www.rfc-editor.org/info/rfc4380>.


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


Brian Carpenter и C. M. Heard представили полезные замечания к черновому варианту документа. Daniel Migault провел углубленный обзор, который помог улучшить текст документа. Amanda Baber и Sabrina Tanamal задавали вопросы, которые помогли авторам упростить документ.


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


Ronald Bonica


Juniper Networks


Email: rbonica@juniper.net


Michelle Cotton


PTI, an affiliate of ICANN


12025 Waterfront Drive, Suite 300


Los Angeles, CA 90094-2536


United States of America


Phone: +1-424-254-5300


Email: michelle.cotton@iana.org


Brian Haberman


Johns Hopkins University


Email: brian@innovationslab.net


Leo Vegoda


ICANN


Email: leo.vegoda@icann.org




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


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


nmalykh@protokols.ru 




1Internet Engineering Task Force.






2Internet Engineering Steering Group.






3См. раздел 5 в [RFC4380].






4См. [RFC4193] для описания маршрутизируемости адресов Unique-Local. Префикс Unique-Local берется из диапазона IPv6 Global Unicast Address, но указан как не маршрутизируемый глобально.



 							

	
			

									
						Рубрика: RFC					
					|
				
				
				Комментарии к записи RFC 8190 Updates to the Special-Purpose IP Address Registries отключены

							

		


		
	

	
			

			
RFC 8175 Dynamic Link Exchange Protocol (DLEP)


			

				Опубликовано 16.06.2017 автором Nikolai Malykh			


					

				
Internet Engineering Task Force (IETF)                        S. Ratliff
Request for Comments: 8175                                    VT iDirect
Category: Standards Track                                        S. Jury
ISSN: 2070-1721                                            Cisco Systems
                                                          D. Satterwhite
                                                                Broadcom
                                                               R. Taylor
                                                  Airbus Defence & Space
                                                                B. Berry
                                                               June 2017



Dynamic Link Exchange Protocol (DLEP)


Протокол DLEP


PDF


Аннотация


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


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


Документ относится к категории Internet Standards Track.


Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.


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


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


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


К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).


1. Введение


В настоящее время имеется множество модемных устройств, управляющих каналами с переменной скоростью и качеством. Примерами таких устройств являются наземные станции радиоканалов прямой видимости (LOS4), спутниковые терминалы и широкополосные модемы. Флуктуации скорости икачества этих каналов могут меняться из-за настроек или изменения физических условий, таких как интерференция отраженных сигналов, препятствия, затухание при дожде и т. п. Вполне возможна зависимость скорости и качества канала от конечной точки и типа передаваемого трафика. В качестве примера рассмотрим точку доступа IEEE 802.11, обслуживающую два связанных переносных компьютера. В этой среде ответом скорость соединения 802.11 будет зависеть от используемых компьютеров и типа передаваемого трафика. Один из компьютеров, расположенный ближе к точке доступа, может иметь, например, скорость 54 Мбит/с для индивидуального (unicast) трафика, а расположенный дальше другой компьютре — всего лишь 32 Мбит/с для такого же трафика. Однако групповой трафик от точки доступа будет передаваться с базовой скоростью, которая настраивается, но обычно не превышает 24 Мбит/с.


Кроме каналов с переменной скоростью мобильные сети сталкиваются с проблемой подключения и отключения устройств, не влияющего на состояние интерфейса маршрутизатора (Up или Down). Эффективное использование сравнительно краткосрочного соединения является проблематичным в сетях с маршрутизацией IP, поскольку протоколы маршрутизации IP опираются на состояния интерфейсов и независимые таймеры для поддержки сходимости сети (например, сообщения HELLO и/или распознавание маршрутной смежности DEAD). Такие динамические соединения могут использоваться лучше в парадигме управления по событиям, где обретение нового соседа или потеря имеющегося ведет к сигналу, нежели в парадигме управления по таймерам и/или состоянию интерфейса. Протокол DLEP не только реализует парадигму управления по событиям, но и делает это на уровне локальной (1 интервал — hop) сессии TCP, что гарантирует доставку сообщений.


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


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


|-----Локальный узел-----|          |------Удаленный узел----|
|                        |          |                        |
+--------+       +-------+          +-------+       +--------+
|Маршрути|=======| Модем |{~~~~~~~~}| Модем |=======|Маршрути|
|  затор |       |       |          |       |       |  затор |
+--------+       +-------+          +-------+       +--------+
         |       |       | Канальный|       |       |
         |-DLEP--|       | протокол |       |-DLEP--|
         |       |       |(например,|       |       |
         |       |       | 802.11)  |       |       |


Рисунок 1. Сеть DLEP.


На рисунке 1 локальный модем при обнаружении наличия удаленного узла передает сообщение своему маршрутизатору по протоколу DLEP. Это сообщение содержит указание произошедшего на канале изменения (например, появление или исчезновение узла) вместе с набором определенных DLEP эдементов данных (Data Item) с дополнительным описанием изменения. При получении этого сообщения локальный маршрутизатор может предпринять действие, которое он считает целесообразным, такое как запуск протоколов обнаружения и/или выдачу сообщений HELLO для схождения сети. Далее по мере необходимости модемы используют DLEP для информирования об изменении характеристик (скорость, задержка и т. п.) канала. Протокол DLEP не зависит от типа канала и поддерживаемой модемом топологии. Протокол предназначен для использования лишь на локальном канале  между маршрутизатором и модемом. Может потребоваться та или иная сигнализация (over-the-air) между локальным и удаленным модемом для обеспечения некоторых параметров сообщений DLEP между локальным модемом и локальным маршрутизатором, но DLEP не задает способ такой сигнализации (определяется производителем модема).


На рисунке 2 показано, как DLEP может поддерживать конфигурацию при подключении маршрутизаторов по разнотипным каналам. В этом примере модемы типа A организуют соединение «точка-точка», а модемы типа B соединяются через общую среду. В обоих случаях используется протокол DLEP для информирования маршрутизаторов о характеристиках канала (скорость, задержка и т. п.). Модем также может использовать сессию DLEP для уведомления маршрутизатора о потере удаленного узла для сокращения времени схождения сети.




         +--------+                     +--------+
    +----+ Модем  |                     | Модем  +---+
    |    |  типа  |                     |  типа  |   |
    |    |    A   |  <===== // ======>  |    A   |   |
    |    +--------+ Канал «точка-точка» +--------+   |
+---+----+                                       +---+----+
|Маршрути|                                       |Маршрути|
|  затор |                                       |  затор |
+---+----+                                       +---+----+
    |     +--------+                     +--------+  |
    +-----+ Модем  |                     | Модем  |  |
          |  типа  |   o o o o o o o o   |  типа  +--+
          |    B   |    o   Общая   o    |    B   |
          +--------+     o  среда  o     +--------+
                          o       o
                           o     o
                            o   o
                              o
                         +--------+
                         | Модем  |
                         |  типа  |
                         |    B   |
                         +---+----+
                             |
                         +---+----+
                         |Маршрути|
                         |  затор |
                         +--------+


Рисунок 2. Сеть DLEP с несколькими модемами.


2. Обзор протокола


Протокол DLEP определяет набор сообщений, используемых модемами и подключенными к ним маршрутизаторами для обмена событиями, которые происходят на физических каналах, поддерживаемых модемом (например, подключение или отключение узла сети, изменение канала). С этими сообщениями связан набор элементом данных (Data Item), описывающих удаленный узел (например, информация об адресе) и/или характеристики канала к удаленному узлу. В этом документе модемы и маршрутизаторы, участвующие в сессии DLEP, называются участниками (DLEP Participant), если не требуется более конкретное указание (например, модем или маршрутизатор).


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


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


2.1. Получатели


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


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


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


Примером логического получателя является групповая адресация (Multicast). Групповой трафик для сети с изменяющимся качеством соединения (доступ через модем) обрабатывается в IP-сети путем выведения адресов L2 (MAC) из адресов L3. В такой схеме групповой трафик поддерживается протоколом DLEP просто трактовкой выведенных MAC-адресов, как любых других получателей в сети.


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


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


2.2. Соглашения и терминология


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


3. Требования


Протокол DLEP должен разворачиваться в одном домене L2. Протокол указывает получателей следующего интервала (next-hop), используя MAC-адрес для доставки трафика данных. Каких-либо подстановок или манипуляций не происходит и MAC-адрес из сообщений DLEP используется в качестве Destination MAC в кадрах, передаваемых участвующим в протоколе маршрутизатором. MAC-адреса должны быть уникальными в контексте сессии модем-маршрутизатор.


Для ограничения работы одним доменом L2 реализации должны поддерживать механизм Generalized TTL Security Mechanism [RFC5082], а также должны следовать этой спецификации для всех сообщений DLEP.


DLEP задает групповой трафик UDP для сигнализации обнаружения в одном интервале (single-hop discovery) и TCP — для доставки сообщений. Модемы и маршрутизаторы, участвующие в сессии DLEP, должны иметь топологически согласованные адреса IP. Рекомендациям DLEP рекомендуется использовать адреса IPv6 link-local для снижения административных издержек, связанных с назначением адресов.


DLEP полагается на гарантированную доставку сообщений между модемом и маршрутизатором после завершений процесса обнаружения (1-hop discovery), поэтому для доставки сообщений выбран протокол TCP. Можно применять и другие протоколы с гарантией доставки, но это выходит за рамки данного документа.


4. Варианты развертывания


В процессе разработки спецификации рассматривались два типа развертывания.


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


Другой вариант можно считать «сетевым развертыванием». В этом случае маршрутизатор и модемы DLEP размещаются в доступном извне сегменте сети. Здесь между маршрутизатором и конкретным модемом DLEP может быть несколько физических узлов пересылки. В этом варианте требуется использовать туннель L2 для выполнения требования DLEP в части 1 этапа пересылки (single-hop).


5. Допущения


DLEP предполагает наличие протокола сигнализации между модемами, участвующими в работе. Данная спецификация не задает поведение этой беспроводной (over-the-air) сигнализации, но предполагает передачу (возможность вывода) некой информации, такой как подключение и отключение модемов, а также вариации харакетристик канала между модемами. Предполагается, что эти данные модем использует для реализации DLEP.


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


 6. Параметры метрики


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


DLEP позволяет передавать метрику в двух контекстах — для конкретного получателя в сети (например, определенного маршрутизатора) и «на уровне сессии» (применительно ко всем адресатам, доступным через модем). Большинство показателей можно разделить на параметры передачи и приема. Когда метрика предоставляется на уровне сессии, маршрутизатор распространяет параметры на все записи в базе данных для получателей, доступных через модем.


Модем DLEP анонсирует все метрические элементы данных, о которых он будет сообщать в сессии, и указывает для параметров принятые по умолчанию значения в сообщенииSession Initialization Response (12.6. Отклик Session Initialization Response). Для использования типа метрики, не включенного в такое сообщение, модем прерывает сеанс с маршрутизатором сообщением Session Termination (12.9. Сообщение Session Termination) и начинает новую сессию.


Модем DLEP может в любое время передать метрику (1) в контексте сессии через сообщение Session Update (12.7. Сообщение Session Update) и (2) в контексте конкретного адресата — через Destination Update (12.17. Сообщение Destination Update). Более новые данные метрики имеют преимущество независимо от контекста передачи.


    

  1. 

    Если метрика получена в контексте адресата (Destination Update), обновляются данные для получателя.
    

    2. 

  2. 

    Если метрика получена в контексте сессии (Session Update), обновляются параметры для всех получателей, подключенных через этот модем.
    

    3. 



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


В дополнение к обмену метрическими данными каналов в DLEP поддерживаются сообщения, позволяющие маршрутизатору запросить у модема другую скорость или задержку. Это сообщения Link Characteristics Request (12.18. Запрос характеристик канала), которые дают маршрутизатору возможность более детерминированно справляться с ростом (снижением) запросов на выделение полосы и задержку.


 7. Состояния сессии DLEP


Все участники сессии DLEP проходят через множество состояний в течение срока действия сессии DLEP:


    

  • 

    обнаружения партнера (Peer Discovery);
    

    • 

  • 

    инициализация сессии (Session Initialization);
    

    • 

  • 

    работа сессии (In-Session);
    

    • 

  • 

    прерывание сессии (Session Termination);
    

    • 

  • 

    сброс сессии (Session Reset).
    

    • 



Модемы и маршрутизаторы, поддерживающие обнаружение DLEP, проходят через все перечисленные состояния. Маршрутизаторы, полагающиеся на заранее настроенные адрес и порт TCP, начинают с состояния Session Initialization.


Модемы должны поддерживать состояние Peer Discovery.


 7.1. Состояние Peer Discovery


Модемы должны поддерживать состояние Peer Discovery, маршрутизаторы могут поддерживать сигналы обнаружения или полагаться на конфигурацию для нахождения модемов. Если маршрутизатор выбирает поддержку детектирования DLEP, он должен поддерживать все сигналы.


В состоянии Peer Discovery маршрутизатор, поддерживающие обнаружение DLEP, должен передавать Peer Discovery Signal (12.3. Сигнал Peer Discovery ) для инициирования процесса обнаружения модема.


После этого маршрутизатор ждет отклика Peer Offer (12.4. Сигнал Peer Offer ) от модема DLEP. В состоянии Peer Discovery сигналы Peer Discovery должны передаваться маршрутизатором DLEP периодически. Рекомендуется интервал 60 секунд. Интервал должен быть не меньше 1 секунды и следует делать его настраиваемым. Отметим, что эта операция (передача Peer Discovery и ожидание Peer Offer) не входит в модель транзакций DLEP (8. Модель транзакций), поскольку эта модель описывает лишь сообщения в сессии TCP.


Маршрутизатор, получивший сигнал Peer Offer, должен использовать одну из комбинаций адрес-порт в Peer Offer для организации соединения TCP с модемом даже при наличии заданной ранее конфигурации. При наличии нескольких Connection Point в полученной Peer Offer маршрутизатору следует предпочитать точки подключения IPv6 точкам IPv4. При наличии нескольких точек с одним протоколом (IPv6 или IPv4) реализация может использовать свю эвристику для выбора среди них. Если соединение TCP не удается организовать с любой из пар адрес-порт и механизм Discovery применяется, маршрутизатору следует возобновить передачу сигналов Peer Discovery. Если элементов Connection Point нет в сигнале Peer Offer, маршрутизатор должен использовать адрес отправителя из пакета UDP, содержащего Peer Offer, в качестве IP-адреса получателя и общеизвестный порт DLEP.


В состоянии Peer Discovery реализация модема должна слушать входящие сигналы Peer Discovery на общеизвестном порту DLEP группового локального адреса IPv6 и/или IPv4. При получении действительного сигнала Peer Discovery модем должен ответить сигналом Peer Offer.


Модемы должны быть готовы воспринять соединение TCP от маршрутизаторов, не использующих механизм Discovery, т. е. попытки соединения без предшествующего сигнала Peer Discovery.


Реализациям DLEP следует поддерживать и использовать протокол TLS7 [RFC5246] для защиты сессии TCP. «Выделенные развертывания» (4. Варианты развертывания) могут использовать DLEP без TLS. Для всех «сетевых развертываний» настоятельно рекомендуется поддерживать и использовать TLS. При использовании TLS сеанс протокола TLS должен быть организован до начала передачи каких-либо сообщений между партнерами. Маршрутизаторы, поддерживающие TLS, должны предпочитать точки соединения, использующие TLS.


После организации соединения TCP (и сессии TLS, если протокол используется), модем и маршрутизатор переходят в состояние Session Initialization. Продожение отправки сигналов Peer Discovery после перехода в состояние Session Initialization реализация выбирает самостоятельно. Реализации модемов должны игнорировать сигналы Peer Discovery от маршрутизатора, с которым уже организовано соединение TCP.


 7.2. Состояние Session Initialization


При переходе в состояние Session Initialization маршрутизатор должен передать модему сообщение Session Initialization (12.5. Сообщение Session Initialization). затем маршрутизатор должен дождаться сообщения Session Initialization Response (12.6. Отклик Session Initialization Response) от модема. Прием Session Initialization Response с элементом данных (13.1. Данные состояния) Status, имеющим значение 0 ‘Success’ (таблица 2 в параграфе 13.1. Данные состояния), указывает, что модем получил и обработал сообщение Session Initialization и маршрутизатор должен перейти в состояние In-Session.


При переходе в состояние Session Initialization модем должен ждать от маршрутизатора сообщения Session Initialization. При получении Session Initialization модем должен передать сообщение Session Initialization Response, а затем должен перейти в состояние In-Session. При получении иного сообщения или отказе при анализе принятого Session Initialization модему недопустимо передавать какое-либо сообщение и он должен разорвать соединение TCP connection, а также перейти в состояние Session Reset.


DLEP поддерживает возможность согласования расширений в состоянии Session Initialization (9. Расширения). Поддерживаемые реализацией расширения должны быть объявлены возможным участникам DLEP с использованием элемента данных Extensions Supported (13.6. Extensions Supported). После обмена обоих участников DLEP инициализационными сообщениями реализации недопустимо передавать какие-либо сообщения, сигналы, элементы данных или коды состояния, связанные с расширениями, которые не были указаны в инициализационном сообщении от партнера.


 7.3. Состояние In-Session


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


Состояние In-Session поддерживается, пока не произойдет любое из приведенных ниже событий:


    

  • 

    прерывание сессии сообщением Session Termination (12.9. Сообщение Session Termination);
    

    • 

  • 

    прерывание сессии партнером с помощью сообщения Session Termination.
    

    • 



В этом случае реализация должна перейти в состояние Session Termination.


 7.3.1. Сообщения Heartbeat


Для поддержки состояния In-Session периодически должны передаваться сообщения Heartbeat (12.20. Сообщение Heartbeat) между модемами и маршрутизаторами. Эти сообщения предназначены для сохранения сессии путем двухсторонней проверки связности между участниками DLEP. Рекомендуется устанавливать между сообщениями интервал 60 секунд. Интервал должен быть не менее 1 секунды и следует делать его настраиваемым.


Каждый участник DLEP отвечает за создание сообщений Heartbeat.


При получении любого действительного сообщения DLEP таймер сообщений Heartbeat должен сбрасываться в 0 (т. е. любое действительное сообщение выступает в качестве Heartbeat).


Реализация должна разрешать по меньшей мере 2 интервала без сообщений прежде, чем разрывать сессию с партнером. При разрыве сеанса должно передаваться сообщение Session Termination Message с элементом данных Status (13.1. Данные состояния), имеющим значение 132 ‘Timed Out’ (Таблица 2), после чего реализация должна перейти в состояние Session Termination.


 7.4. Состояние Session Termination


При переходе реализации в состояние Session Termination после отправки сообщения Session Termination (12.9. Сообщение Session Termination) в результате ошибки или приема нейдествительного сообщения она должна дождать от партнера сообщения Session Termination Response (12.10. Отклик Session Termination Response). Отправителю следует выждать 4 интервал Heartbeat прежде, чем счесть партнера недоступным и продолжить разрыв сессии. Любые другие сообщения в процессе такого ожидания должны игнорироваться.


Когда отправитель Session Termination получает от партнера сообщение Session Termination Response или завершается время ожидания, отправитель должен перейти в состояние Session Reset.


Когда реализация получает от партнера сообщение Session Termination, она переходит в состояние Session Termination, а затем должна незамедлительно передать сообщение Session Termination Response и перейти в состояние Session Reset.


 7.5. Состояние Session Reset


В состоянии Session Reset реализация должна выполнить указанные ниже действия:


    

  • 

    освободить все выделенные для сессии ресурсы;
    

    • 

  • 

    удалить всех получателей в базе данных, представленных сессией; передача сообщений Destination Down (12.15. Сообщение Destination Down) недопустима;
    

    • 

  • 

    разорвать соединение TCP.
    

    • 



По завершении указанных действий реализации следует вернуться в подходящее исходное состояние:


    

  • 

    модем — Peer Discovery;
    

    • 

  • 

    маршрутизатор — Peer Discovery или Session Initialization в зависимости от конфигурации.
    

    • 



 7.5.1. Неожиданный разрыв сессии TCP


Если соединение TCP между участниками DLEP разрывается, когда реализация не находится в состоянии Session Reset, реализация должна незамедлительно перейти в состояние Session Reset.


 8. Модель транзакций


DLEP определяет простую модель транзакций для сообщений — в сессии может обрабатываться лишь один запрос на каждого получателя. Транзакция считается завершенной, когда получен отклик, соответствующий переданному ранее запросу. Если участник DLEP получает запрос для получателя, применительно к которому уже имеется незавершенный запрос, реализация должна прервать сессию сообщением Session Termination (12.9. Сообщение Session Termination), содержащим элемент данных Status (13.1. Данные состояния) с кодом 129 ‘Unexpected Message’ (Таблица 2), и перейти в состояние Session Termination. Не задается ограничений на общее число обрабатываемых одновременно транзакций, если каждая из них относится к своему получателю.


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


Кроме того, в каждый момент может обрабатываться лишь один сеансовый запрос, например, Session Initialization (12.5. Сообщение Session Initialization). Как отмечено выше, транзакция для сообщения считается завершенной при получении отклика, соответствующего переданному ранее запросу. Если участник DLEP получает сеансовый запрос в то время, когда обрабатывается другой сеансовый запрос, он должен прервать сессию сообщением Session Termination, содержажим элемент данных Status с кодом 129 ‘Unexpected Message’ и перейти в состояние Session Termination. Во время обработы сеансовой транзакции могут вводиться лишь сообщения Session Termination. Сообщения Heartbeat (12.20. Сообщение Heartbeat) недопустимо считать частью сеансовой транзакции.


Для транзакций DLEP не предусмотрены отказы и тайм-ауты, за исключением транзакий, не завершенных к моменту сброса сессии DLEP. При прерывании сессии отмена незавершенных транзакций должна выполняться как часть сброса конечного автомата состояний. Реализация может обнаруживать отказ партнера используя механизм Heartbeat в состоянии In-Session (7.3. Состояние In-Session).


 9. Расширения


Расширения должны согласовываться на уровне сессии в процессе ее инициализации с помощью механизма Extensions Supported. Реализации в плане соответствия DLEP не обязана поддерживать какие-либо расширения.


Если требуются совместимые расширения протокола, они должны быть стандартизованы путем (1) обновления данного документа или (2) создания отдельной спецификации. Реестры IANA, указанные в разделе 15, содержат достаточно неискользованных кодов для сигналов, сообщений, элементов данных и состояний DLEP, что позволяет расширять протокол.


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


 9.1. Экспериментальные расширения


Этот жокумент регистрирует пространство номеров Private Use [RFC5226] для сигналов, сообщений, элементов данных и кодов состояния DLEP, предназначенное для экспериментальных расширений. Цель заключается в предоставлении возможности экспериментировать с новыми сигналами, сообщениями, элементами данных и состояниями, сохраняя документированное поведение DLEP.


В процессе инициализации сеанса использование приватных (Private Use) значений для сигналов, сообщений, элементов данных и/или состояний должно анонсироваться как расширения DLEP с применением идентификаторов из пространства Private Use в реестре Extension Type Values (Таблица 3) с заранее согласованным между участниками значением. Расширения DLEP из пространства номеров Private Use обычно называются экспериментальными.


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


 10. Масштабируемость


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


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


 11. Структура сигналов и сообщений DLEP


DLEP определяет два протокольных блока, используемых разными способами, — сигналы и сообщения. Сигналы используются лишь механизмом обнаружения и передаются в дейтаграммах UDP. Сообщения передаются в обоих направлениях через соединения TCP между участниками в состояниях Session Initialization, In-Session, Session Termination.


Сигналы и сообщения включают заголовок, за которым следует неупорядоченный список элементов данных. Заголовок содержит поля типа (Type) и размера (Length), а элементы данных используют формат TLV (тип-размер—значение). Элементы данных после заголовка сигнала или сообщения называют содержащимися в сигнале или сообщении.


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


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


 11.1. Заголовок сигнала DLEP


Поля заголовка сигнала DLEP показаны на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      'D'      |      'L'      |      'E'      |      'P'      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type                   | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Рисунок 3. Заголовок сигнала DLEP.



«DLEP»


Каждый сигнал должен начинаться с последовательности символовU+0044, U+004C, U+0045, U+0050.


Signal Type


16-битовое целое число без знака, указывающее одно из значений DLEP Signal Type, определенных в документе.


Length 


16-битовое целое число без знака, указывающее размер (в октетах) всех элементов данных, содержащихся в этом сигнале. В размере элементов данных DLEP недопустимо учитывать размер самого Signal Header.


После заголовка сигнала DLEP могут следовать элементы данных DLEP (Data Item) в формате TLV.


 11.2. Заголовок сообщения DLEP


Поля заголовка сообщения DLEP показаны на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type                  | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Рисунок 4. Заголовок сообщения DLEP.



Message Type


16-битовое целое число без знака, содержащее одно из значений DLEP Message Type, определенных в документе.


Length


16-битовое целое число без знака, указывающее размер (в октетах) всех элементов данных, содержащихся в этом сообщении. В размере элементов данных DLEP недопустимо учитывать размер самого Message Header.


После заголовка сообщения DLEP могут следовать элементы данных DLEP (Data Item) в формате TLV.


 11.3. Базовый элемент данных DLEP


Все элементы данных DLEP используют показанный на рисунке заголовок.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Value...                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Рисунок 5. Базовый элемент данных DLEP.



Data Item Type


16-битовое целое число без знака, указывающее один из типов Data Item.


Length


16-битовое целое число без знака, указывающее размер (в октетах) поля Value в элементе данных. В этом поле  недопустимо учитывать размер полей Data Item Type и Length.


Value


Поле размером Length октетов, содержащее данные конкретного Data Item.


 12. Сигналы и сообщения DLEP


 12.1. Базовые правила обработки


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


Если сигнал получен со значением TTL не равным 255, принимающая реализация должна игнорировать сигнал.


При получении нераспознанного сообщения принимающая реализация должна выдать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент данных Status (13.1. Данные состояния) с кодом 128 ‘Unknown Message’ (Таблица 2), и перейти в состояние Session Termination.


При получении неожиданного сообщения принимающая реализация должна выдать сообщение Session Termination, содержащее элемент данных Status с кодом 129 ‘Unexpected Message’, и перейти в состояние Session Termination.


Если полученное сообщение содержит нараспознанный или недействительный элемент данных или не разрешенные дубликаты Data Item, принимающая реализация должна выдать сообщение Session Termination, содержащее элемент данных Status с кодом 130 ‘Invalid Data’, и перейти в состояние Session Termination.


Если пакет в потоке TCP получен со значением TTL, отличным от 255, принимающая реализация должна незамедлительно перейти в состояние Session Reset.


Перед обменом сообщениями Destination Up (12.11. Сообщение Destination Up) и Destination Up Response (12.12. Отклик Destination Up Response) или Destination Announce (12.13. Сообщение Destination Announce) и Destination Announce Response (12.14. Отклик Destination Announce Response) нельзя передавать сообщения, относящиеся к адресатам. Реализация, принявшая сообщение с неанонсированным адресатом, должна прервать сессию сообщением Session Termination, с элементом данных Status = 131 ‘Invalid Destination’ и перейти в состояние Session Termination.


После обмена сообщениями Destination Down (12.15. Сообщение Destination Down) и Destination Down Response (12.16. Отклик Destination Down Response) не допускается передача других сообщений об адресатах, пока не будет выполнен новый обмен Destination Up или Destination Announce. Реализация, получившая сообщение об адресате, ранее объявленном как отключенный (down), должна прервать сессию сообщением Session Termination, с элементом данных Status = 131 ‘Invalid Destination’ и перейти в состояние Session Termination.


 12.2. Обработка кода состояния


Поведение участника DLEP при получении элемента данных Status (13.1. Данные состояния) определяется режимом отказа, связанным с кодом состояния (Таблица 2). Для всех кодов меньше 100 при отказе выполнение продолжается (Continue), для остальных кодов — прерывается (Terminate).


Участник DLEP, получивший сообщение, отличное от Session Termination (12.9. Сообщение Session Termination), с элементом данных Status, для которого задан режим Terminate, должен незамедлительно передать сообщение Session Termination, включив в него полученный элемент Status, а затем перейти в состояние Session Termination.


Участник DLEP при получении сообщения, содержащего элемент данных Status, для которого задан режим Continue, может продолжать обычное использование сессии.


 12.3. Сигнал Peer Discovery


Сигнал Peer Discovery маршрутизатору DLEP следует передавать для обнаружения в сети модемов DLEP (7.1. Состояние Peer Discovery.


Сигнал Peer Discovery должен передаваться в пакете UDP. В качестве получателя должен указываться общеизвестный адрес и порт DLEP. Маршрутизаторам, поддерживающим работу DLEP по протоколам IPv4 и IPv6, рекомендуется выбирать транспорт IPv6. В качестве IP-адреса отправителя должен устанавливаться адрес маршрутизатора, связанный с интерфейсом DLEP. Для порта отправителя DLEP не задает требований.


Для создания Peer Discovery Signal устанавливается Signal Type = 1 в Signal Header (15.2. Типы сигналов).


Сигнал Peer Discovery может включать Peer Type Data Item (13.4. Peer Type).


 12.4. Сигнал Peer Offer


Сигнал Peer Offer должен передаваться модемом DLEP в ответ на корректно отформатированный и адресованный сигнал Peer Discovery (12.3. Сигнал Peer Discovery ).


Сигнал Peer Offer должен передаваться в пакете UDP. Поля отправителя и получателя IP должны быть значениями из сигнала Peer Discovery, которые поменяны местами. Сигнал Peer Offer завершает процесс обнаружения (7.1. Состояние Peer Discovery).


Для создания Peer Offer Signal устанавливается Signal Type = 2 в Signal Header (15.2. Типы сигналов).


Сигнал Peer Offer Signal может включать Peer Type Data Item (13.4. Peer Type).


Сигнал Peer Offer Signal может включать один или несколько перечисленных ниже Data Item с разными значениями:


    

  • 

    IPv4 Connection Point (13.2. IPv4 Connection Point);
    

    • 

  • 

    IPv6 Connection Point (13.3. IPv6 Connection Point).
    

    • 



Эти элементы указывают индивидуальные адреса, которые маршрутизатор должен использовать в сессии DLEP TCP.


 12.5. Сообщение Session Initialization


Сообщение Session Initialization маршрутизатор DLEP должен передавать как первое сообщение в сессии DLEP TCP. Оно передается маршрутизатором после организации соединения TCP через адрес и порт, полученные в соотщении Peer Offer или заданные в конфигурации.


При создании сообщения Session Initialization устанавливается Message Type = 1 в Message Header (15.3. Регистрации Message Type).


Сообщение Session Initialization должно содержать по одному из перечисленных ниже элементов данных:


    

  • 

    Heartbeat Interval (13.5. Heartbeat Interval)
    

    • 

  • 

    Peer Type (13.4. Peer Type)
    

    • 



При поддержке расширения DLEP сообщение Session Initialization должно содержать элемент данных Extensions Supported (13.6. Extensions Supported).


Сообщение Session Initialization может включать 1 или несколько перечисленных ниже элементов данных с разными значениями и установленным (1) флагом Add/Drop (A) (13. Элементы данных DLEP):


    

  • 

    IPv4 Address (13.8. IPv4 Address);
    

    • 

  • 

    IPv6 Address (13.9. IPv6 Address);
    

    • 

  • 

    IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
    

    • 

  • 

    IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).
    

    • 



Если реализация поддерживает необязательные расширения, они должны быть указаны в элементе данных Extensions Supported. Если элемента Extensions Supported нет в сообщении Session Initialization, модем должен считать, что маршрутизатор не поддерживает расширений.


Сообщения DLEP Heartbeat не передаются до приема сообщения Session Initialization Response (12.6. Отклик Session Initialization Response), поэтому реализация должна применять свою эвристику для времени ожидания.


Исключением из общего правила поведения реализации, получившей в сообщении непонятный элемент данных (12.1. Базовые правила обработки), является сообщение Session Initialization с 1 или несколькими элементами Extensions Supported, анонсирующими поддержку непонятных для реализации расширений. Реализация может игнорировать непонятные элементы данных.


 12.6. Отклик Session Initialization Response


Сообщение Session Initialization Response модем DLEP должен передавать в ответ на Session Initialization (12.5. Сообщение Session Initialization).


При создании сообщения Session Initialization Response устанавливается Message Type = 2 в заголовке сообщения (15.3. Регистрации Message Type).


Сообщение Session Initialization Response должно содержжать по одному элементу данных, указанному ниже:


    

  • 

    Status (13.1. Данные состояния);
    

    • 

  • 

    Peer Type (13.4. Peer Type);
    

    • 

  • 

    Heartbeat Interval (13.5. Heartbeat Interval);
    

    • 

  • 

    Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
    

    • 

  • 

    Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
    

    • 

  • 

    Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
    

    • 

  • 

    Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
    

    • 

  • 

    Latency (13.16. Latency).
    

    • 



Сообщение Session Initialization Response должно включать по одному из перечисленных ниже элементов данных, если он используется в сессии:


    

  • 

    Resources (13.17. Resources);
    

    • 

  • 

    Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
    

    • 

  • 

    Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
    

    • 

  • 

    Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).
    

    • 



Если поддерживаются расширения DLEP, сообщение Session Initialization Response должно содержать элемент данных Extensions Supported (13.6. Extensions Supported).


Сообщение Session Initialization Response может включать 1 или несколько перечисленных ниже элементов данных с разными значениями и установленным (1) флагом Add/Drop (A) (13. Элементы данных DLEP):


    

  • 

    IPv4 Address (13.8. IPv4 Address);
    

    • 

  • 

    IPv6 Address (13.9. IPv6 Address);
    

    • 

  • 

    IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
    

    • 

  • 

    IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).
    

    • 



Сообщение Session Initialization Response завершает организацию сессии DLEP. Модему следует переходить в состояние In-Session, когда это сообщение передано, а маршрутизатору следует переходить в In-Session при получении приемлемого сообщения Session Initialization Response.


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


Если модем поддерживает необязательные расширения, они должны быть указаны в элементе данных Extensions Supported. Если элемента Extensions Supported нет в сообщении Session Initialization Response, маршрутизатор должен считать, что модем не поддерживает расширений. После обмена сообщениями Session Initialization и Session Initialization Response реализация должна использовать лишь расширения, поддерживаемые обоими участниками DLEP (7.2. Состояние Session Initialization).


 12.7. Сообщение Session Update


Сообщение Session Update может передать участник DLEP в рамках сессии для индикации смены локального адреса L3 и/или метрических параметров.


В заголовке Session Update устанавливается Message Type = 3 (15.3. Регистрации Message Type).


Сообщение Session Update может включать 1 или несколько указанных элементов данных с разными значениями:


    

  • 

    IPv4 Address (13.8. IPv4 Address);
    

    • 

  • 

    IPv6 Address (13.9. IPv6 Address);
    

    • 

  • 

    IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
    

    • 

  • 

    IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).
    

    • 



При передаче модемом сообщение Session Update может включать 1 или несколько элементов данных:


    

  • 

    Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
    

    • 

  • 

    Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
    

    • 

  • 

    Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
    

    • 

  • 

    Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
    

    • 

  • 

    Latency (13.16. Latency).
    

    • 



При передаче модемом сообщение Session Update может включать 1 или несколько перечисленных ниже элементов данных, если они используются в сессии:


    

  • 

    Resources (13.17. Resources);
    

    • 

  • 

    Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
    

    • 

  • 

    Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
    

    • 

  • 

    Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).
    

    • 



Если в Session Update представлены параметры метрики (например, Maximum Data Rate), эти параметры считаются относящимися к сессии в целом и должны применяться ко всем адресатам из информационной базы, связанной с сессией DLEP. Это включает адресатов, для которых метрика может быть сохранена на основе полученных сообщений Destination Update.


Следует отметить, что сообщения Session Update могут передавать модемы и маршрутизаторы. Например, добавление адреса IPv4 на маршрутизаторе может служить основанием для сообщения Session Update подключенным модемам. Аналогично, смена модемом Maximum Data Rate (Receive) для всех адресатов может быть отражена в сообщении Session Update для подключенных маршрутизаторов.


Если модем способен понимать и пересылать информацию об адресах и подсетях L3 (механизмы не определены в DLEP), изменение таких сведений побудит все удаленные модемы с поддержкой DLEP передать Destination Update своим локальным маршрутизаторам с указанием новых (или удаленных) адресов и подсетей.


 12.8. Отклик Session Update Response


Сообщение Session Update Response должно передаваться участником DLEP в ответ на Session Update (12.7. Сообщение Session Update).


В заголовке Session Update Response устанавливается Message Type = 4 (15.3. Регистрации Message Type).


Сообщение Session Update Response должно включать элемент данных Status (13.1. Данные состояния).


 12.9. Сообщение Session Termination


Когда участник DLEP принимает решение о необходимости прервать сессию DLEP, он должен передать (или попытаться) сообщение Session Termination.


В заголовке Session Termination устанавливается значение Message Type = 5 (15.3. Регистрации Message Type).


Сообщение Session Termination должно включать элемент данных Status (13.1. Данные состояния).


Следует отметить, что сообщения Session Termination могут передавать как модемы, так и маршрутизаторы.


 12.10. Отклик Session Termination Response


Сообщение Session Termination Response должно передаваться участником DLEP в ответ на Session Termination Message (12.9. Сообщение Session Termination).


В заголовке Session Termination Response устанавливается Message Type = 6 (15.3. Регистрации Message Type).


Элементы данных ни включаются в Session Termination Response.


Прием сообщения Session Termination Response завершает разпыв сессии DLEP (7.4. Состояние Session Termination).


 12.11. Сообщение Destination Up


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


В заголовке Destination Up устанавливается значение Message Type = 7 (15.3. Регистрации Message Type).


Сообщение Destination Up должно включать элемент данных MAC Address (13.7. MAC Address).


В сообщение Destination Up следует включать 1 или несколько перечисленных ниже Data Item с разными значениями:


    

  • 

    IPv4 Address (13.8. IPv4 Address);
    

    • 

  • 

    IPv6 Address (13.9. IPv6 Address).
    

    • 



Сообщение Destination Up может включать по одному из перечисленных ниже элементов данных:


    

  • 

    Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
    

    • 

  • 

    Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
    

    • 

  • 

    Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
    

    • 

  • 

    Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
    

    • 

  • 

    Latency (13.16. Latency).
    

    • 



Сообщение Destination Up может включать по 1 из перечисленных ниже элементов данных, если этот элемент используется в сессии:


    

  • 

    Resources (13.17. Resources);
    

    • 

  • 

    Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
    

    • 

  • 

    Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
    

    • 

  • 

    Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).
    

    • 



Сообщение Destination Up может включать по 1 из перечисленных ниже элементов данных с разными значениями:


    

  • 

    IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
    

    • 

  • 

    IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).
    

    • 



Маршрутизатор, получивший Destination Up выделяет необходимые ресурсы, создает в информационной базе запись с указанными значениями (MAC Address, Latency, Data Rate и т. п.) для получателя. Информация об этом получателе будет сохраняться в базе до получения маршрутизатором сообщения Destination Down (12.15. Сообщение Destination Down), указывающего, что модем потерял связь с удаленным узлом или реализация перешла в состояние Session Termination.


 12.12. Отклик Destination Up Response


Маршрутизатор должен передавать сообщение Destination Up Response в ответ на Destination Up (12.11. Сообщение Destination Up) is received.


В заголовке Destination Up Response устанавливается Message Type = 8 (15.3. Регистрации Message Type).


Сообщение Destination Up Response должно содержать по одному из перечисленных ниже элементов данных:


    

  • 

    MAC Address (13.7. MAC Address);
    

    • 

  • 

    Status (13.1. Данные состояния).
    

    • 



Маршрутизатор, желающий получить дополнительную информацию о получателе, указанном в соответствующем сообщении Destination Up, должен установить в отклике Status = 0 ‘Success’ (Таблица 2). Если маршрутизатор не заинтересован в получателе, указанном в соответствующем сообщении Destination Up, он может установить в отклике Status = 1 ‘Not Interested’.


Модему, получившему Destination Up Response с элементом Status, отличным от 0 ‘Success’, недопустимо передавать другие сообщения Destination для этого адресата, например, Destination Down (12.15. Сообщение Destination Down) или Destination Update (12.17. Сообщение Destination Update) с тем же MAC-адресом.


 12.13. Сообщение Destination Announce


Обычно модем обнаруживает присутствие одной или нескольких удаленных пар модем-маршрутизатор и анонсирует появление каждого получателя передачей маршрутизатору соответствующего сообщения Destination Up (12.11. Сообщение Destination Up). Однако могут быть случаи, когда маршрутизатор хочет выразить интерес к адресату, который еще не анонсирован (обычно групповой адресат). В таких случаях маршрутизатор может передать сообщение Destination Announce для обозначения своего интереса.


Сообщение Destination Announce маршрутизатор может также отправлять для запроса информации о получателе, (1) интерес к которому был ранее отвергнут статусом 1 ‘Not Interested’ в сообщении Destination Up Response (12.12. Отклик Destination Up Response, Таблица 2) или (2) который раньше был объявлен отключенным (down), в сообщении Destination Down (12.15. Сообщение Destination Down).


В заголовке сообщения Destination Announce указывается Message Type = 9 (15.3. Регистрации Message Type).


Сообщение Destination Announce должно включать элемент данных MAC Address (13.7. MAC Address).


Сообщение Destination Announce может содержать перечисленные ниже элементы данных с разными значениями:


    

  • 

    IPv4 Address (13.8. IPv4 Address);
    

    • 

  • 

    IPv6 Address (13.9. IPv6 Address).
    

    • 



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


 12.14. Отклик Destination Announce Response


Модем должен передавать сообщение Destination Announce Response в ответ на Destination Announce (12.13. Сообщение Destination Announce).


При создании Destination Announce Response устанавливается Message Type = 10 (15.3. Регистрации Message Type) в заголовке сообщения. Сообщение Destination Announce Response должно содержать по одному элементу данных:


    

  • 

    MAC Address (13.7. MAC Address);
    

    • 

  • 

    Status (13.1. Данные состояния).
    

    • 



Destination Announce Response может включать один или несколько элементов данных с разными значениями:


    

  • 

    IPv4 Address (13.8. IPv4 Address);
    

    • 

  • 

    IPv6 Address (13.9. IPv6 Address);
    

    • 

  • 

    IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
    

    • 

  • 

    IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).
    

    • 



Сообщение Destination Announce Response может включать по одному элементу данных, перечисленных ниже:


    

  • 

    Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
    

    • 

  • 

    Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
    

    • 

  • 

    Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
    

    • 

  • 

    Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
    

    • 

  • 

    Latency (13.16. Latency).
    

    • 



Destination Announce Response может включать по одному элементу данных, если он применяется в сессии:


    

  • 

    Resources (13.17. Resources);
    

    • 

  • 

    Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
    

    • 

  • 

    Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
    

    • 

  • 

    Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).
    

    • 



Если модем не способен незамедлительно сообщить запрошенные сведения (например, адресат в данный момент не доступен), он должен возвратить элемент данных Status = 2 ‘Request Denied’ (Таблица 2).


После передачи сообщения Destination Announce Response с элементом данных Status Data, содержащим отличное от 0 ‘Success’ значение, модем изменения на канале к адресату в сообщении Destination Update.


При получении Destination Announce Response маршрутизатору следует добавить данные об адресате в свою информационную базу.


 12.15. Сообщение Destination Down


Модем должен передавать сообщение Destination Down для информирования о недоступности адресата (удаленный узел или multicast-группа).


Маршрутизатор может передать Destination Down для онформирования о том, что ему больше не нужна информация о получателе.


При создании Destination Down устанавливается значение Message Type = 11 в Message Header (15.3. Регистрации Message Type).


Сообщение Destination Down должно включать элемент данных MAC Address (13.7. MAC Address).


Следует отметить, что сообщения Destination Down могут передавать как модемы, так и маршрутизаторы, независимо от того, кто из них сообщил первым об активности (up) адресата.


 12.16. Отклик Destination Down Response


Сообщение Destination Down Response должно передаваться получателем Destination Down (12.15. Сообщение Destination Down) для подтверждения того, что относящиеся к этому адресату данные удалены из базы.


В заголовке Destination Down Response указывается Message Type = 12 (15.3. Регистрации Message Type).


Сообщение Destination Down Response должно содержать по одному элементу данных:


    

  • 

    MAC Address (13.7. MAC Address);
    

    • 

  • 

    Status (13.1. Данные состояния).
    

    • 



 12.17. Сообщение Destination Update


Модему следует передавать сообщение Destination Update при обнаруженииизменений в информационной базе для нанного адресата (удаленный узел или multicast-группа). Примерами изменений, вызывающих передачу Destination Update, являются:


    

  • 

    изменение метрики канала (например, скорости);
    

    • 

  • 

    смена адреса L3.
    

    • 



В заголовке Destination Update указывается Message Type = 13 (15.3. Регистрации Message Type).


Сообщение Destination Update должно включать элемент данных MAC Address (13.7. MAC Address).


Destination Update может включать по одному из перечисленных элементов данных:


    

  • 

    Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
    

    • 

  • 

    Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
    

    • 

  • 

    Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
    

    • 

  • 

    Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
    

    • 

  • 

    Latency (13.16. Latency).
    

    • 



Destination Update может включать по одному из указанных элементов данных, если он применяется в сессии:


    

  • 

    Resources (13.17. Resources);
    

    • 

  • 

    Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
    

    • 

  • 

    Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
    

    • 

  • 

    Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).
    

    • 



Destination Update может включать один или несколько элементов данных с разными значениями, указанных ниже:


    

  • 

    IPv4 Address (13.8. IPv4 Address);
    

    • 

  • 

    IPv6 Address (13.9. IPv6 Address);
    

    • 

  • 

    IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
    

    • 

  • 

    IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).
    

    • 



Параметры метрики, указанные в сообщении, переопределяют парметры, полученные ранее в сообщениях Session, Destination, Link Characteristics (например, Session Initialization, Destination Up, Link Characteristics Response).


Следует отметить, что для этого сообщения нет соответствующего отклика.


 12.18. Запрос характеристик канала


Маршрутизатор может передавать сообщение Link Characteristics Request, чтобы запросить у модема инициирование изменений определенных характеристик канала. Запрос может указывать реального (например, удаленный узел) или логического (например, multicast-группу) адресата в сети.


В заголовке Link Characteristics Request указывается Message Type = 14 (15.3. Регистрации Message Type).


Сообщение Link Characteristics Request должно включать элемент данных MAC Address (13.7. MAC Address).


Сообщение Link Characteristics Request должно также включать по меньшей мере по одному элементу данных:


    

  • 

    Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
    

    • 

  • 

    Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
    

    • 

  • 

    Latency (13.16. Latency).
    

    • 



Link Characteristics Request может включать один из элементов данных Current Data Rate (Receive) (CDRR) или Current Data Rate (Transmit) (CDRT) для запроса отличной от текущей скорости, а также элемент Latency для запроса значения максимальной задержки на канале.


Передающему сообщение маршрутизатору следует понимать, что выполнение запроса Link Characteristics Request может занять достаточно продолжительное время.


 12.19. Отклик с характеристиками канала


Модем должен отвечать сообщением Link Characteristics Response при получении Link Characteristics Request (12.18. Запрос характеристик канала).


В заголовке Link Characteristics Response указывается Message Type = 15 (15.3. Регистрации Message Type).


Сообщение Link Characteristics Response должно включать по одному элементу данных:


    

  • 

    MAC Address (13.7. MAC Address);
    

    • 

  • 

    Status (13.1. Данные состояния).
    

    • 



В сообщение Link Characteristics Response следует включать по одному элементу данных:


    

  • 

    Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
    

    • 

  • 

    Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
    

    • 

  • 

    Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
    

    • 

  • 

    Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
    

    • 

  • 

    Latency (13.16. Latency).
    

    • 



Сообщение Link Characteristics Response может включать по одному элементу перечисленных ниже данных, если такой элемент применяется в сессии:


    

  • 

    Resources (13.17. Resources);
    

    • 

  • 

    Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
    

    • 

  • 

    Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
    

    • 

  • 

    Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).
    

    • 



Сообщение Link Characteristics Response должно включать полный набор элементов данных метрики, указывая все параметры, объявленные в Session Initialization Response (12.6. Отклик Session Initialization Response). Значения метрических параметров в Link Characteristics Response должны отражать характеристики канала после выполнения запроса.


Если реализация не способна изменить характеристики канала в соответствии с запросом, она должна указать элемент данных Status с кодом 2 ‘Request Denied’ (Таблица 2).


 12.20. Сообщение Heartbeat


Сообщение Heartbeat должно передаваться участником DLEP каждые N мсек, где N задается элементом данных Heartbeat Interval (13.5. Heartbeat Interval) в сообщении Session Initialization (12.5. Сообщение Session Initialization) или Session Initialization Response (12.6. Отклик Session Initialization Response).


При создании сообщения Heartbeat устанавливается значение Message Type = 16 в Message Header (15.3. Регистрации Message Type).


Элементы данных не используются в сообщениях Heartbeat.


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


 13. Элементы данных DLEP


Элементы данных DLEP (Data Item) перечислены в таблице.


Таблица 1. Типы элементов данных DLEP.





 





Код типа




Описание








0




Резерв








1




Status (13.1. Данные состояния)








2




IPv4 Connection Point (13.2. IPv4 Connection Point)








3




IPv6 Connection Point (13.3. IPv6 Connection Point)








4




Peer Type (13.4. Peer Type)








5




Heartbeat Interval (13.5. Heartbeat Interval)








6




Extensions Supported (13.6. Extensions Supported)








7




MAC Address (13.7. MAC Address)








8




IPv4 Address (13.8. IPv4 Address)








9




IPv6 Address (13.9. IPv6 Address)








10




IPv4 Attached Subnet (13.10. IPv4 Attached Subnet)








11




IPv6 Attached Subnet (13.11. IPv6 Attached Subnet)








12




Maximum Data Rate (Receive) (MDRR) (13.12. Maximum Data Rate (Receive))








13




Maximum Data Rate (Transmit) (MDRT) (13.13. Maximum Data Rate (Transmit))








14




Current Data Rate (Receive) (CDRR) (13.14. Current Data Rate (Receive))








15




Current Data Rate (Transmit) (CDRT) (13.15. Current Data Rate (Transmit))








16




Latency (13.16. Latency)








17




Resources (RES) (13.17. Resources)








18




Relative Link Quality (Receive) (RLQR) (13.18. Relative Link Quality (Receive))








19




Relative Link Quality (Transmit) (RLQT) (13.19. Relative Link Quality (Transmit))








20




Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU))








21-65407




Не выделены (доступны для будущих расширений)








65408-65534




Резерв для приватного использования (доступны для экспериментов)








65535




Резерв








 13.1. Данные состояния


Для сообщений Session Termination (12.9. Сообщение Session Termination) элемент данных Status Data указывает причину разрыва сессии. В остальных сообщениях этот элемент указывает успех или отказ предыдущего полученного сообщения.


Элемент Status Data включает необязательное поле Text, в котором может размещаться текстовое описание статуса. Использование поля Text полностью отдано на откуп принимающей реализации, например, оно может быть записано в системный журнал или просто отброшено. При отсутствии поля Text в элементе данных Status поле Length должно иметь значение 1. Структура Status Data Item показана на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code   | Text...                                       :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


1


Length


1 + размер Text (в октетах).


Status Code


Один из кодов состояния, указанных в таблице 2.


Text


Строка с кодировкой UTF-8 [RFC3629], описывающая причину состояния для целей, определяемых реализацией. Поскольку это поле служит для описания, реализации следует использовать лишь печатаемые символы. Реализации недопустимо считать поле Text строкой печатаемых символов с NUL-завершением.


Таблица 2. Коды состояния DLEP.







 





Код




Режим




Описание




Причина








0




Продолжение




Успех




Сообщение успешно обработано.








1




Продолжение




Не интересно




Получатель не заинтересован в предмете (теме) данного сообщения, например, в сообщении Destination Up Response (12.12. Отклик Destination Up Response), для индикации отсутствия других сообщений о получателе.








2




Продолжение




Запрос отвергнут




Получатель отверг выполнение запроса.








3




Продолжение




Несогласованные данные




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








4-111




Продолжение




<Не выделено>




Для использования в будущем.








112-127




Продолжение




<Резерв для приватного использования>




Доступно для экспериментов.








128




Прерывание




Неизвестное сообщение




Сообщение не распознано реализацией.








129




Прерывание




Неожиданное сообщение




Сообщение не ожидается в текущем состоянии. Например, сообщение Session Initialization (12.5. Сообщение Session Initialization) в In-Session.








130




Прерывание




Недействительные данные




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








131




Прерывание




Недействительный адресат




Адресат, указанный в сообщении, не соответствует анонсированному ранее, например, в сообщении Link Characteristics Response (12.19. Отклик с характеристиками канала).








132




Прерывание




Тайм-аут 




Истекло время ожидания в сессии.








133-239




Прерывание




<Не выделено>




Для использования в будущем.








240-254




Прерывание




<Резерв для приватного использования>




Доступно для экспериментов.








255




Прерывание




Отключение




Партнер прерывает сессию по причине отключения.








 13.2. IPv4 Connection Point


Элемент данных IPv4 Connection Point Data Item указывает адрес IPv4 и может также задавать номер порта TCP на модеме для организации соединения. При наличии информации маршрутизатор должен использовать ее для организации соединения TCP с модемом. Формат IPv4 Connection Point показан на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |               IPv4 Address...                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:  ...cont.     |   TCP Port Number (необязат)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


2


Length


5 (или 7 при включении порта TCP).


Flags


Поле флагов, описанных ниже.


IPv4 Address


Адрес IPv4, прослушиваемый модемом.


TCP Port Number


Номер порта TCP в модеме.


Если Length = 7, заданный номер порта должен использоваться для организации сессии TCP. Если порт TCP не указан (Length = 5), маршрутизатор должен использовать стандартный порт DLEP (15.4. Регистрации DLEP Data Item).


Поле Flags имеет форму, показанную на рисунке.


 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |T|
+-+-+-+-+-+-+-+-+



T


Флаг использования TLS, указывающий, защищено (1) или нет (0) соединение TCP с помощью TLS [RFC5246].


Reserved


Биты зарезервированы для использования в будущем и должны быть сброшены (0).


 13.3. IPv6 Connection Point


Элемент данных IPv6 Connection Point Data Item указывает адрес IPv6 и может также задавать номер порта TCP на модеме для организации соединения. При наличии информации маршрутизатор должен использовать ее для организации соединения TCP с модемом. Формат IPv6 Connection Point показан на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |                IPv6 Address                   :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:  ...cont.     |   TCP Port Number (optional)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


3


Length


17 (или 19 при включении порта TCP).


Flags


Поле флагов, описанных ниже.


IPv6 Address


Адрес IPv6, прослушиваемый модемом.


TCP Port Number


Номер порта TCP в модеме.


Если Length = 19, заданный номер порта должен использоваться для организации сессии TCP. Если порт не указан (Length = 17), маршрутизатор должен использовать стандартный порт DLEP (15.4. Регистрации DLEP Data Item).


Поле Flags имеет форму, показанную на рисунке.


 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |T|
+-+-+-+-+-+-+-+-+



T


Флаг использования TLS, указывающий, защищено (1) или нет (0) соединение TCP с помощью TLS [RFC5246].


Reserved


Биты зарезервированы для использования в будущем и должны быть сброшены (0).


 13.4. Peer Type


Элемент данных Peer Type используется маршрутизаторами и модемами для указания дополнительных сведений о типе и свойствах беспроводной (over-the-air) плоскости управления.


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


Peer Type Data Item включает текстовое описание партнера, которое предполагается используемым для информационных целей (например, для вывода на дисплей). Поля элемента данных Peer Type показаны на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         | Description...                                :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


4


Length


1 + размер Description (в октетах).


Flags


Поле флагов, описанных ниже.


Description


Текстовая строка UTF-8 [RFC3629]. Например, спутниковый модем может задать строку «Satellite terminal». Поскольку это поле предназначено для задания дополнительной информации в командах отображения, следует использовать в поле только печатаемые символы.


Реализациям недопустимо предполагать, что строка Description является строкой печатаемых символом с NUL-символом в конце.


 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |S|
+-+-+-+-+-+-+-+-+



Поле Flags имеет форму, показанную на рисунке.


S


Флаг защищенной среды (Secured Medium), используемый модемом для указания контроля доступа к общей среде (RF) — (1) указывает контролируемый доступ, (0) — отсутствие контроля. Флаг имеет значение лишь в сигналах и сообщениях, передаваемых модемом.


Reserved


Биты зарезервированы для использования в будущем и должны быть сброшены (0).


 13.5. Heartbeat Interval


Элемент данных Heartbeat Interval используется для задания периода (в мсек) передачи сообщений Heartbeat (12.20. Сообщение Heartbeat). Формат Heartbeat Interval Data Item показан на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Heartbeat Interval                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


5


Length


4


Heartbeat Interval


Интервал (в миллисекундах) между сообщениями Heartbeat, указанный 32-битовым целым числом без знака. Значение 0 недопустимо.


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


 13.6. Extensions Supported


Элемент данных Extensions Supported используется модемами и маршрутизаторами для согласования дополнительных функций, которые могут поддерживаться. Поле Extensions List содержит конкатенацию типов поддерживаемых расширений из реестра IANA Extension Type Values. Каждле определение Extension Type указывает дополнительные сигналы и элементы данных, которые будут поддерживаться. Формат элемента данных показан ниже.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions List...                                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


6


Length


Размер поля Extensions List в октетах (удвоенное число расширений.


Extensions List


Список поддерживаемых расширений, указанных 2-октетными значениями из реестра Extension Type Values.


 13.7. MAC Address


Элемент данных MAC Address содержит адрес получателя на удаленном узле.


DLEP может поддерживать MAC-адреса в формате EUI8-48 и EUI-64, но все адреса в данной сессии DLEP должны иметь один формат и должны соответствовать MAC-адресу на подключенном модеме (например, если модем подключен к маршрутизатору EUI-48 MAC, все получатели, доступные через этот модем, должны использовать EUI-48).


Примерами виртуальных адресатов могут служить (1) групповой MAC-адрес (2) или широковещательный MAC-адрес FF:FF:FF:FF:FF:FF.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      MAC Address                              :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                MAC Address    :     (для EUI-64)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


7


Length


6 для формата EUI-48 или 8 для EUI-64.


MAC Address


MAC-адрес получателя.


 13.8. IPv4 Address


При включении в сообщение Session Update этот элемент данных содержит партнерский адрес IPv4, а в сообщениях Destination — адреса IPv4 для получателей. В любом случае элемент данных включает также индикацию того, задает ли этот элемент (1) новый или имеющийся адрес или (2) удаление известного ранее адреса. Формат элемента IPv4 Address показан на рисунке.



 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         | IPv4 Address                                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:  ...продолж.  |
+-+-+-+-+-+-+-+-+


Data Item Type


8


Length


5


Flags


Поле флагов, описанное ниже.


IPv4 Address


Адрес IPv4 для адресата или партнера.


Поле Flags имеет вид, показанный на рисунке.


 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |A|
+-+-+-+-+-+-+-+-+



A


Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).


Reserved


Резерв на будущее (должны иметь значение 0).


 13.8.1. Обработка IPv4 Address


Обработка IPv4 Address должна выполняться в контексте сессии DLEP, где представлен элемент. Обработка ошибочных или логически противоречивых случаев зависит от типа сообщения в элементом данных и описана ниже.


Если сообщение относится к сессии, например, Session Initialization (12.5. Сообщение Session Initialization) или Session Update (12.7. Сообщение Session Update), получатель противоречивых данных должен передать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент Status (13.1. Данные состояния) с кодом 130 ‘Invalid Data’ и перейти в состояние Session Termination. Примеры таких случаев включают:


    

  • 

    операцию Drop для адреса, не связанного с партнером в текущей сессии;
    

    • 

  • 

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

    • 



Если сообщение относится к адресату, например, Destination Up (12.11. Сообщение Destination Up) или Destination Update (12.17. Сообщение Destination Update), получатель противоречивых данных может передать отклик с элементом Status = 3 ‘Inconsistent Data’, но должен продолжать обработу сессии. Примерами могут служить:


    

  • 

    операция Add для адреса, который уже добавлен получателю в текущей сессии;
    

    • 

  • 

    операция Add для адреса, который связан с другим адресатом или партнером в текущей сессии;
    

    • 

  • 

    операция Add для адреса, который не имеет смысла, например, определен как непересылаемый [RFC6890];
    

    • 

  • 

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

    • 



Если нет сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.


Модемы, не отслеживающие адреса IPv4, должны игнорировать элементы данных IPv4 Address.


 13.9. IPv6 Address


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         | IPv6 Address                                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address  |
+-+-+-+-+-+-+-+-+



В сообщении Session Update этот элемент данных содержит партнерский адрес IPv6, а в Destination — адреса IPv6 для получателей. В любом случае элемент данных включает также индикацию того, задает ли этот элемент (1) новый или имеющийся адрес или (2) удаление известного ранее адреса. Формат элемента IPv6 Address показан на рисунке.


Data Item Type


9


Length


17


Flags


Поле флагов, описанное ниже.


IPv6 Address


Адрес IPv6 для адресата или партнера.


Поле Flags имеет форму, показанную на рисунке.


 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |A|
+-+-+-+-+-+-+-+-+



A


Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).


Reserved


Резерв на будущее (должны иметь значение 0).


 13.9.1. Обработка IPv6 Address


Обработка IPv6 Address должна выполняться в контексте сессии DLEP, где представлен элемент. Обработка ошибочных или логически противоречивых случаев зависит от типа сообщения в элементом данных и описана ниже.


Если сообщение относится к сессии, например, Session Initialization (12.5. Сообщение Session Initialization) или Session Update (12.7. Сообщение Session Update), получатель противоречивых данных должен передать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент Status (13.1. Данные состояния) с кодом 130 ‘Invalid Data’ и перейти в состояние Session Termination. Примеры таких случаев включают:


    

  • 

    операцию Drop для адреса, не связанного с партнером в текущей сессии;
    

    • 

  • 

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

    • 



Если сообщение относится к адресату, например, Destination Up (12.11. Сообщение Destination Up) или Destination Update (12.17. Сообщение Destination Update), получатель противоречивых данных может передать отклик с элементом Status = 3 ‘Inconsistent Data’, но должен продолжать обработу сессии. Примерами могут служить:


    

  • 

    операция Add для адреса, который уже добавлен получателю в текущей сессии;
    

    • 

  • 

    операция Add для адреса, который связан с другим адресатом или партнером в текущей сессии;
    

    • 

  • 

    операция Add для адреса, который не имеет смысла, например, определен как непересылаемый [RFC6890];
    

    • 

  • 

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

    • 



Если нет подходящего сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.


Модемы, не отслеживающие адреса IPv6, должны игнорировать элементы данных IPv6 Address.


 13.10. IPv4 Attached Subnet


Элемент данных DLEP IPv4 Attached Subnet позволяет устройству объявить о подключенной к нему подсети IPv4 (например, оконечной сети) и указать, что ему известно о присутствии или потере подсети у удаленного адресата. Элемент IPv4 Attached Subnet имеет форму, показанную на рисунке.



 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Flags        |          IPv4 Attached Subnet                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...продолж.   |Prefix Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type


10


Length


6


Flags


Поле флагов, описанное ниже.


IPv4 Attached Subnet


Подсеть IPv4 доступная у адресата.


Prefix Length


Размер префикса (0-32) подсети IPv4. Префиксы, выходящие за указанный диапазон, должны считаться недействительными.


 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |A|
+-+-+-+-+-+-+-+-+



Поле Flags имеет форму, показанную на рисунке.


A


Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).


Reserved


Резерв на будущее (должны иметь значение 0).


 13.10.1. Обработка IPv4 Attached Subnet


Обработка IPv4 Attached Subnet должна выполняться в контексте сессии DLEP, где представлен элемент.


Если сообщение относится к сессии, например, Session Initialization (12.5. Сообщение Session Initialization) или Session Update (12.7. Сообщение Session Update), получатель противоречивых данных должен передать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент Status (13.1. Данные состояния) с кодом 130 ‘Invalid Data’ и перейти в состояние Session Termination. Примеры таких случаев включают:


    

  • 

    операцию Drop для подсети, не связанной с партнером в текущей сессии;
    

    • 

  • 

    операцию Add для подсети, которая уже добавлена партнеру в текущей сессии.
    

    • 



Если сообщение относится к адресату, например, Destination Up (12.11. Сообщение Destination Up) или Destination Update (12.17. Сообщение Destination Update), получатель противоречивых данных может передать отклик с элементом Status = 3 ‘Inconsistent Data’, но должен продолжать обработу сессии. Примерами могут служить:


    

  • 

    операция Add для подсети, которая уже добавлена получателю в текущей сессии;
    

    • 

  • 

    операция Add для подсети, которая связана с другим адресатом или партнером в текущей сессии;
    

    • 

  • 

    операция Add для подсети, которая не имеет смысла, например, определена как непересылаемая [RFC6890];
    

    • 

  • 

    операцию Drop для подсети, не связанной с получателем в текущей сессии.
    

    • 



Если нет подходящего сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.


Модемы, не отслеживающие подсети IPv4, должны игнорировать элементы данных IPv4 Attached Subnet.


 13.11. IPv6 Attached Subnet


Элемент данных DLEP IPv6 Attached Subnet позволяет устройству объявить о подключенной к нему подсети IPv6 (например, оконечной сети) и указать, что ему известно о присутствии или потере подсети у удаленного адресата. Элемент IPv6 Attached Subnet имеет форму, показанную на рисунке.


  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |         IPv6 Attached Subnet                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                   IPv6 Attached Subnet                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                   IPv6 Attached Subnet                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                   IPv6 Attached Subnet                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...продолж.   | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


11


Length


18


Flags


Поле флагов, описанное ниже.


IPv6 Attached Subnet


Подсеть IPv6 доступная у адресата.


Prefix Length


Размер префикса (0-128) подсети IPv6. Префиксы, выходящие за указанный диапазон, должны считаться недействительными.


 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |A|
+-+-+-+-+-+-+-+-+



Поле Flags имеет форму, показанную на рисунке.


A


Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).


Reserved


Резерв на будущее (должны иметь значение 0).


 13.11.1. Обработка IPv6 Attached Subnet


Обработка IPv6 Attached Subnet должна выполняться в контексте сессии DLEP, где представлен элемент. Обработка ошибочных или логически противоречивых случаев зависит от типа сообщения в элементом данных и описана ниже.


Если сообщение относится к сессии, например, Session Initialization (12.5. Сообщение Session Initialization) или Session Update (12.7. Сообщение Session Update), получатель противоречивых данных должен передать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент Status (13.1. Данные состояния) с кодом 130 ‘Invalid Data’ и перейти в состояние Session Termination. Примеры таких случаев включают:


    

  • 

    операцию Drop для подсети, не связанной с партнером в текущей сессии;
    

    • 

  • 

    операцию Add для подсети, которая уже добавлена партнеру в текущей сессии.
    

    • 



Если сообщение относится к адресату, например, Destination Up (12.11. Сообщение Destination Up) или Destination Update (12.17. Сообщение Destination Update), получатель противоречивых данных может передать отклик с элементом Status = 3 ‘Inconsistent Data’, но должен продолжать обработу сессии. Примерами могут служить:


    

  • 

    операция Add для подсети, которая уже добавлена получателю в текущей сессии;
    

    • 

  • 

    операция Add для подсети, которая связана с другим адресатом или партнером в текущей сессии;
    

    • 

  • 

    операция Add для подсети, которая не имеет смысла, например, определена как непересылаемая [RFC6890];
    

    • 

  • 

    операцию Drop для подсети, не связанной с получателем в текущей сессии.
    

    • 



Если нет подходящего сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.


Модемы, не отслеживающие подсети IPv6, должны игнорировать элементы данных IPv6 Attached Subnet.


 13.12. Maximum Data Rate (Receive)


Элемент данных Maximum Data Rate (Receive) (MDRR) служит для указания максимальной теоретически доступной скорости (бит/с) приема данных на канале. Формат Maximum Data Rate (Receive) показан на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MDRR (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        MDRR (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


12


Length


8


Maximum Data Rate (Receive)


64-битовое целое число без знака, указывающее максимальную теоретическую скорость приема (бит/с) на канале.


 13.13. Maximum Data Rate (Transmit)


Элемент данных Maximum Data Rate (Transmit) (MDRT) служит для указания максимальной теоретически доступной скорости (бит/с) приема данных на канале. Формат Maximum Data Rate (Transmit) показан на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MDRT (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        MDRT (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


13


Length


8


Maximum Data Rate (Transmit)


64-битовое целое число без знака, задающее максимальную теоретическую скорость передачи (бит/с) на канале.


 13.14. Current Data Rate (Receive)


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        CDRR (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        CDRR (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Элемент данных Current Data Rate (Receive) (CDRR) служит для указания текущей скорости (бит/с) приема данных на канале. При использовании в сообщении Link Characteristics Request Message (12.18. Запрос характеристик канала), Current Data Rate (Receive) представляет желаемую скорость приема в канале (бит/с). Формат Current Data Rate (Receive) показан на рисунке.


Data Item Type


14


Length


8


Current Data Rate (Receive)


64-битовое целое число без знака, указывающее текущую доступную скорость приема (бит/с) на канале.


Если Current Data Rate (Receive) и Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive)) не различаются, значение Current Data Rate (Receive) должно устанавливаться равным Maximum Data Rate (Receive). Для Current Data Rate (Receive) недопустимо превышать значение Maximum Data Rate (Receive).


 13.15. Current Data Rate (Transmit)


Элемент данных Current Data Rate (Transmit) (CDRR) служит для указания текущей скорости (бит/с) передачи данных на канале. При использовании в сообщении Link Characteristics Request Message (12.18. Запрос характеристик канала), Current Data Rate (Transmit) представляет желаемую скорость передачи в канале (бит/с). Формат Current Data Rate (Transmit) показан на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        CDRT (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        CDRT (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


15


Length


8


Current Data Rate (Transmit)


64-битовое целое число без знака, указывающее текущую доступную скорость передачи (бит/с) на канале.


Если Current Data Rate (Transmit) и Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit)) не различаются, значение Current Data Rate (Receive) должно устанавливаться равным Maximum Data Rate (Transmit). Для Current Data Rate (Transmit) недопустимо превышать значение Maximum Data Rate (Transmit).


 13.16. Latency


Элемент данных Latency служит для укаазния задержки на канале в микросекундах. Значение Latency указывает задержку при передаче. Расчет задержки зависит от реализации, например, это может быть средняя задержка, рассчитанная из внутренней очереди. Формат элемента данных Latency показан на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Latency                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           Latency                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Data Item Type


16


Length


8


Latency


64-битовое целое число без знака, указывающую задержку при передаче пакетов по каналу в микросекундах.


 13.17. Resources


Элемент данных Resources (RES) служит для указания количества ограниченных (конечных) ресурсов, доступных для передачи и приема данных у адресата, в процентах от 0 (нет ресурсов) до 100 (полный доступ), в предположении прекращения передачи и приема данных при Resources = 0. Примером таких ресурсов может служить заряд батареи, память для очередей, загрузка процессора. Конкретные критерии выходят за рамки спецификации и зависят от реализации. Элемент данных предназначен для индикации тех или иных возможностей модема и/или маршрутизатора на стороне получателя. Формат элемента данных представлен на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RES       |
+-+-+-+-+-+-+-+-+



Data Item Type


17


Length


1


Resources


8-битовое целое число без знака, указывающее доступность ресурса в процентах (0-100). Значения больше 100 должны считаться недействительными.


Если устройство не может рассчитать Resources, использование элемента данных недопустимо.


 13.18. Relative Link Quality (Receive)


Элемент данных Relative Link Quality (Receive) (RLQR) служит для индикации качества приема на канале к получателю в процентах. 0 указывает минимальное качество, 100 — наилучшее. Качество в данном контексте определяется стабильностью приема на канале — предполагается, что получатель с высоким значением Relative Link Quality (Receive) имеет стабильные параметры метрики DLEP, а при низком Relative Link Quality (Receive) метрика канала может быстро меняться в широком диапазоне. Формат Relative Link Quality (Receive) показан на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RLQR      |
+-+-+-+-+-+-+-+-+



Data Item Type


18


Length


1


Relative Link Quality (Receive)


8-битовое целое число без знака, указывающее относительное качество приема в процентах (0-100). Значения больше 100 должны считаться недействительными.


Если устройство не может рассчитать Relative Link Quality (Receive), использование элемента данных недопустимо.


 13.19. Relative Link Quality (Transmit)


Элемент данных Relative Link Quality (Transmit) (RLQT) служит для индикации качества передачи на канале к получателю в процентах. 0 указывает минимальное качество, 100 — наилучшее. Качество в данном контексте определяется стабильностью передачи на канале — предполагается, что получатель с высоким значением Relative Link Quality (Transmit) имеет стабильные параметры метрики DLEP, а при низком Relative Link Quality (Transmit) метрика канала может быстро меняться в широком диапазоне. Формат Relative Link Quality (Transmit) показан на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RLQT      |
+-+-+-+-+-+-+-+-+



Data Item Type


19


Length


1


Relative Link Quality (Transmit)


8-битовое целое число без знака, указывающее относительное качество передачи в процентах (0-100). Значения больше 100 должны считаться недействительными.


Если устройство не может рассчитать Relative Link Quality (Transmit), использование элемента данных недопустимо.


 13.20. Maximum Transmission Unit (MTU)


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             MTU               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Элемент данных Maximum Transmission Unit (MTU) используется для указания максимального размера (в октетах) пакетов IP, которые можно передать без фрагментирования (с учетом заголовков, но не считая заголовки нижележащих уровней). Поля Maximum Transmission Unit Data Item показаны на рисунке.


Data Item Type


20


Length


2


Maximum Transmission Unit


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


Если устройство не способно рассчитать MTU, использование этого элемента данных недопустимо.


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


При использовании DLEP может возникать несколько проблем безопасности, отмеченных ниже.


    

  1. 

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

    2. 

  2. 

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

    3. 

  3. 

    Атакующий может подключиться к незащищенной радиосети и инжектировать сигналы (over-the-air), влияющие на сведения, сообщаемые модемом DLEP, что может менять картину пересылки в маршрутизаторе.
    

    4. 



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


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


При использовании на транспортном уровне протокола TLS каждому партнеру следует проверять действительность представленных другим партнером свидетельств (credential) в процессе организации сеанса TLS. При «выделенном развертывании» реализации, пытающийся использовать TLS, может потребоваться использование (1) заранее распространенных (pre-shared) ключей, (2) специальных методов проверки отождествления партнеров (3) или методов [RFC5487]. В модели «сетевого развертывания» (4. Варианты развертывания) следует использовать [RFC7525].


На уровне L2, поскольку работа DLEP ограничена одним интервалом (возможно, логическим), реализациям следует защищать также каналы L2. Примеры методов защиты каналов L2 включают [IEEE-802.1AE] и [IEEE-802.1X].


Проверяя флаг Secured Medium в элементе данных Peer Type (13.4. Peer Type), маршрутизатор может принять решение о доверии к информации, представленной модемом DLEP. В иных случаях маршрутизатору следует рассмотреть вопрос ограничения размера подключенных подсетей путем анонсирования элементов данных IPv4 Attached Subnet (13.10. IPv4 Attached Subnet) и/или IPv6 Attached Subnet (13.11. IPv6 Attached Subnet), учитываемых при выборе маршрута.


Для предотвращения возможных DoS-атак (отказ в обслуживании) реализациям, использующим механизм Peer Discovery, рекомендуется (1) поддерживать в информационной базе список хостов, с которыми были связаны отказы при инициализации сессии, даже если такие хосты предоставляют приемлемый сигнад Peer Discovery, и (2) игнорировать от таких хостов последующие сигналы Peer Discovery.


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


 15. Взаимодействие с IANA


 15.1. Регистрации


Агентство IANA создало новый реестр для протокола Dynamic Link Exchange Protocol (DLEP), включающий описанные ниже субреестры.


 15.2. Типы сигналов


Агентстов IANA создало реестр DLEP под названием Signal Type Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].





 





Код типа




Описания, правила








0




Reserved








1




Peer Discovery Signal








2




Peer Offer Signal








3-65519




Unassigned / Specification Required








65520-65534




Reserved for Private Use








65535




Reserved








 15.3. Регистрации Message Type


Агентство IANA создало реестр DLEP Message Type Values. В таблице приведены исходные значения и правила выделения в соответствии с [RFC5226].





 





Код типа




Описания, правила








0




Резерв








1




Session Initialization








2




Session Initialization Response








3




Session Update








4




Session Update Response








5




Session Termination








6




Session Termination Response








7




Destination Up








8




Destination Up Response








9




Destination Announce








10




Destination Announce Response








11




Destination Down








12




Destination Down Response








13




Destination Update








14




Link Characteristics Request








15




Link Characteristics Response








16




Heartbeat








17-65519




Не выделены, нужна спецификация








65520-65534




Резерв для приватного использования








65535




Резерв








 15.4. Регистрации DLEP Data Item


Агентстов IANA создало реестр DLEP под названием Data Item Type Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].





 





Код типа




Описания, правила








0




Резерв








1




Status








2




IPv4 Connection Point








3




IPv6 Connection Point








4




Peer Type








5




Heartbeat Interval








6




Extensions Supported








7




MAC Address








8




IPv4 Address








9




IPv6 Address








10




IPv4 Attached Subnet








11




IPv6 Attached Subnet








12




Maximum Data Rate (Receive) (MDRR)








13




Maximum Data Rate (Transmit) (MDRT)








14




Current Data Rate (Receive) (CDRR)








15




Current Data Rate (Transmit) (CDRT)








16




Latency








17




Resources (RES)








18




Relative Link Quality (Receive) (RLQR)








19




Relative Link Quality (Transmit) (RLQT)








20




Maximum Transmission Unit (MTU)








21-65407




Не выделены, нужна спецификация








65408-65534




Резерв для приватного использования








65535




Резерв








 15.5. Регистрации DLEP Status Code


Агентстов IANA создало реестр DLEP под названием Status Code Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].






 





Код состояния




Режим




Описания, правила








0




Продолжение




Success








1




Продолжение




Not Interested








2




Продолжение




Request Denied








3




Продолжение




Inconsistent Data








4-111




Продолжение




Не выделены, нужна спецификация








112-127




Продолжение




Приватное использование








128




Прерывание




Unknown Message








129




Прерывание




Unexpected Message








130




Прерывание




Invalid Data








131




Прерывание




Invalid Destination








132




Прерывание




Timed Out








133-239




Прерывание




Не выделены, нужна спецификация








240-254




Прерывание




Резерв для приватного использования








255




Прерывание




Shutting Down








 15.6. Регистрации DLEP Extension


Агентстов IANA создало реестр DLEP под названием Extension Type Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].


Таблица 3. Типы расширений DLEP.





 





Код




Описания, правила








0




 Резерв








1-65519




Не выделены, нужна спецификация








65520-65534




Резерв для приватного использования








65535




Резерв








 15.7. Флаги DLEP IPv4 Connection Point


Агентстов IANA создало реестр DLEP под названием IPv4 Connection Point Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].





 





Бит




Описания, правила








0-6




Не выделены, нужна спецификация.








7




Индикатор использования TLS [RFC5246].








 15.8. Флаги DLEP IPv6 Connection Point


Агентстов IANA создало реестр DLEP под названием IPv6 Connection Point Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].





 





Бит




Описания, правила








0-6




Не выделены, нужна спецификация.








7




Индикатор использования TLS [RFC5246].








 15.9. Флаги DLEP Peer Type


Агентстов IANA создало реестр DLEP под названием Peer Type Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].





 





Бит




Описания, правила








0-6




Не выделены, нужна спецификация.








7




Индикатор использования Secured Medium.








 15.10. Флаги DLEP IPv4 Address


Агентстов IANA создало реестр DLEP под названием IPv4 Address Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].





 





Бит




Описания, правила








0-6




Не выделены, нужна спецификация.








7




Индикатор Add/Drop.








 15.11. Флаги DLEP IPv6 Address


Агентстов IANA создало реестр DLEP под названием IPv6 Address Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].





 





Бит




Описания, правила








0-6




Не выделены, нужна спецификация.








7




Индикатор Add/Drop.








 15.12. Флаги DLEP IPv4 Attached Subnet


Агентстов IANA создало реестр DLEP под названием IPv4 Attached Subnet Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].





 





Бит




Описания, правила








0-6




Не выделены, нужна спецификация.








7




Индикатор Add/Drop.








 15.13. Флаги DLEP IPv6 Attached Subnet


Агентстов IANA создало реестр DLEP под названием IPv6 Attached Subnet Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].





 





Бит




Описания, правила








0-6




Не выделены, нужна спецификация.








7




Индикатор Add/Drop.








 15.14. Порт DLEP


Агентство IANA выделило значение 854 в реестре Service Name and Transport Protocol Port Number Registry (http://www.iana.org/assignments/service-names-port-numbers/) для протокола DLEP, определенного этим документом. Назначение действительно для протоколов TCP и UDP.


 15.15. Групповой адрес DLEP IPv4 Link-Local


Агентство IANA выделило групповой адрес IPv4 224.0.0.117 в реестре http://www.iana.org/assignments/multicast-addresses для DLEP Discovery.


 15.16. Групповой адрес DLEP IPv6 Link-Local


Агентство IANA выделило групповой адрес IPv6 FF02:0:0:0:0:0:1:7 в реестре http://www.iana.org/assignments/ipv6-multicast-addresses для DLEP Discovery.


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


16.1. Нормативные документы


[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.


[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.


[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, «The Generalized TTL Security Mechanism (GTSM)», RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.


[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.


[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.


16.2. Дополнительная литература


[IEEE-802.1AE] «IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Security», DOI 10.1109/IEEESTD.2006.245590, <http://ieeexplore.ieee.org/document/1678345/>.


[IEEE-802.1X] «IEEE Standards for Local and metropolitan area networks—Port-Based Network Access Control», DOI 10.1109/IEEESTD.2010.5409813, <http://ieeexplore.ieee.org/document/5409813/>.


[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.


[RFC5487] Badra, M., «Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode», RFC 5487, DOI 10.17487/RFC5487, March 2009, <http://www.rfc-editor.org/info/rfc5487>.


[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, «Special-Purpose IP Address Registries», BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.


[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, «Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)», BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.


Приложение A. Потоки сигналов обнаружения


Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор инициирует обнаружение,
|                                     запускает таймер и передает сигнал 
|-------Peer Discovery---->X          Peer Discovery.

         ~ ~ ~ ~ ~ ~ ~                Отсчет таймера завершается до приема
                                      Peer Offer.
|                                     
|-------Peer Discovery---------->|    Маршрутизатор повторяет Peer Discovery.
                                 |
                                 |    Модем получает Peer Discovery.
                                 |
                                 |    Модем передает Peer Offer с данными
|<--------Peer Offer-------------|    Connection Point.
:
:                                     Маршрутизатор МОЖЕТ отключить таймер
:                                     обнаружения и прекратить передачу 
:                                     Peer Discovery.


Приложение B. Потоки сообщений на уровне партнеров


 B.1. Инициализация сессии


Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор соединяется с найденной
|--Организовано соединение TCP--->    или заданной Modem Connection Point.
|
|                                     Маршрутизатор передает сообщение
|----Session Initialization----->|    Session Initialization.
                                 |
                                 |    Модем получает сообщение
                                 |    Session Initialization.
                                 |
                                 |    Модем передает сообщение Session 
|<--Session Initialization Resp.-|    Initialization Response с элементом 
|                                |    данных 'Success'.
|                                |
|<<============================>>|    Сессия организована.
:                                :    Начинается передача Heartbeat.


B.2. Отвергнутая инициализация сессии


Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор соединяется с найденной
|--Организовано соединение TCP--->    или заданной Modem Connection Point.
|
|                                     Маршрутизатор передает сообщение
|----Session Initialization----->|    Session Initialization.
                                 |
                                 |    Модем получает сообщение
                                 |    Session Initialization, но не 
                                 |    поддерживает анонсированные расширения.
                                 |
                                 |    Модем передает сообщение Session 
|<--Session Initialization Resp.-|    Initialization Response с элементом 
|                                     данных 'Request Denied'.
|
|
|                                     Маршрутизатор получает негативный отклик
|                                     Session Initialization Response и
||---------TCP close------------||    разрывает соединение TCP.


B.3. Смена IP-адреса маршрутизатора


Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор передает сообщение
|-------Session Update---------->|    Session Update с анонсом смены 
                                 |    адреса IP.
                                 |
                                 |    Модем получает Session Update
                                 |    и обновляет внутреннее состояние.
                                 |
|<----Session Update Response----|    Модем передает Session Update
                                 |    Response.


B.4. Изменение модемом метрики в масштабе сессии


Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                 |    Модем передает Session Update с
|<--------Session Update---------|    анонсом изменения метрики в сессии.
|
|                                     Маршрутизатор получает Session Update
|                                     и обновляет внутреннее состояние.
|
|----Session Update Response---->|    Маршрутизатор передает Session Update
                                 |    Response.


B.5. Разрыв сессии маршрутизатором


Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор передает Session Termination
|------Session Termination------>|    с элементом данных Status.
|                                |
|-------TCP shutdown (send)--->  |    Маршрутизатор прекращает передачу сообщений.
                                 |
                                 |    Модем получает Session Termination,
                                 |    прекращает учет полученных Heartbeat
                                 |    и прекращает передачу Heartbeat.
                                 |
                                 |    Модем передает Session Termination
|<---Session Termination Resp.---|    Response с Status = 'Success'.
|
|                                     Модем прекращает передачу сообщений.
|
||---------TCP close------------||    Сессия прервана.


B.6. Разрыв сессии модемом


Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                 |    Модем передает Session Termination
|<----Session Termination--------|    Message с элементом Status.
|
|                                     Модем прекращает передачу сообщений.
|
|                                     Маршрутизатор получает Session
|                                     Termination,  прекращает учет
|                                     полученных Heartbeat и прекращает
|                                     передачу Heartbeat.
|
|                                     Маршрутизатор передает Session Termination
|---Session Termination Resp.--->|    Response с Status = 'Success'.
                                 |
                                 |    Маршрутизатор прекращает передачу сообщений.
                                 |
||---------TCP close------------||    Сессия прервана.


B.7. Сообщения Heartbeat


Маршрутизатор                Модем    Описание сигнала  
========================================================================
|----------Heartbeat------------>|    Маршрутизатор передает Heartbeat.
                                 |
                                 |    Модем сбрасывает таймер Heartbeat.

         ~ ~ ~ ~ ~ ~ ~

|---------[Any Message]--------->|    Модем получает любое сообщение от
                                 |    маршрутизатора.
                                 |
                                 |    Модем сбрасывает таймер Heartbeat.

         ~ ~ ~ ~ ~ ~ ~

|<---------Heartbeat-------------|    Модем передает Heartbeat.
|
|                                     Маршрутизатор сбрасывает таймер Heartbeat.

         ~ ~ ~ ~ ~ ~ ~

|<--------[Any Message]----------|    Маршрутизатор получает любое сообщение
|                                     от модема.
|
|                                     Маршрутизатор сбрасывает таймер Heartbeat.


B.8. Маршрутизатор определил Heartbeat Timeout


Маршрутизатор                Модем    Описание сигнала  
========================================================================
         X<----------------------|    Маршрутизатор не получает Heartbeat.


|        X<----------------------|    Маршрутизатор не получает несколько
|                                     Heartbeat.
|
|
|------Session Termination------>|    Маршрутизатор передает Session 
|                                     Termination с Status = 'Timeout'
:
:                                     Прерывание...


B.9. Модем определил Heartbeat Timeout


Маршрутизатор                Модем    Описание сигнала  
========================================================================
|---------------------->X             Модем не получает Heartbeat.


|---------------------->X        |    Модем не получает несколько
                                 |    Heartbeat.
                                 |
                                 |
|<-----Session Termination-------|    Модем передает Session Termination
                                 |    с Status = 'Timeout'
                                 :
                                 :    Прерывание...


Приложение C. Потоки сообщений на уровне адресата


 C.1. Уведомления об адресатах


Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                 |    Модем обнаруживает доступность нового 
                                 |    логического адресата и передает 
|<-------Destination Up----------|    Destination Up.
|
|------Destination Up Resp.----->|    Маршрутизатор передает Destination Up
                                 |    Response.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    логического адресата и передает 
|<-------Destination Update------|    Destination Update.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    логического адресата и передает 
|<-------Destination Update------|    Destination Update.

            ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает недоступность
                                 |    логического адресата и передает 
|<-------Destination Down--------|    Destination Down.
|
|                                     Маршрутизатор получает Destination Down,
|                                     обновляет внутреннее состояние и 
|------Destination Down Resp.--->|    передает Destination Down Response.


C.2. Уведомление о групповом адресате


Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор обнаруживает нового
|                                     группового получателя и передает
|-----Destination Announce------>|    Destination Announce.
                                 |
                                 |    Модем обновляет внутреннее состояние
                                 |    для отслеживания группового адресата
|<-----Dest. Announce Resp.------|    и передает Destination Announce
                                      Response.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    группового адресата и передает
|<-------Destination Update------|    Destination Update.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    группового адресата и передает
|<-------Destination Update------|    Destination Update.

            ~ ~ ~ ~ ~ ~ ~
|                                     Маршрутизатор обнаруживает 
|                                     недоступность группового адресата
|--------Destination Down------->|    и передает Destination Down.
                                 |
                                 |    Модем получает Destination Down,
                                 |    обновляет внутреннее состояние и
|<-----Destination Down Resp.----|    передает Destination Down Response.


C.3. Link Characteristics Request


Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                      Адресат уже анонсирован каким-либо
           ~ ~ ~ ~ ~ ~ ~              партнером.

|                                     Модему нужны другие характеристики
|                                     для адресата и он передает Link
|--Link Characteristics Request->|    Characteristics Request.
                                 |
                                 |    Модем пытается настроить свойства
                                 |    канала в соответствии с запросом
                                 |    и передает Link Characteristics
|<---Link Characteristics Resp.--|    Response с новым значением.


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


Спасибо членам группы разработки DLEP, предоставившим бесценную информацию. В эту команду входят Teco Boot, Bow-Nan Cheng, John Dowdell и Henning Rogge.


Хочется также отметить влияние и вклад Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, Vikram Kaul, Nelson Powell, Lou Berger и Victoria Pritchard.


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


Stan Ratliff


VT iDirect


13861 Sunrise Valley Drive, Suite 300


Herndon, VA 20171


United States of America


Email: sratliff@idirect.net


Shawn Jury


Cisco Systems


170 West Tasman Drive


San Jose, CA 95134


United States of America


Email: sjury@cisco.com


Darryl Satterwhite


Broadcom


Email: dsatterw@broadcom.com


Rick Taylor


Airbus Defence & Space


Quadrant House


Celtic Springs


Coedkernew


Newport NP10 8FZ


United Kingdom


Email: rick.taylor@airbus.com


Bo Berry




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


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


nmalykh@protokols.ru




1Dynamic Link Exchange Protocol — протокол динамического обмена информацией о соединениях.






2Internet Engineering Task Force.






3Internet Engineering Steering Group.






4Line-of-sight — прямая видимость.






5Demand Assigned Multiple Access — множественный доступ по запросу.






6Media Access Control — управление доступом к среде.






7Transport Layer Security — защита на транспортном уровне.






8Extended Unique Identifier — расширенный уникальный идентификатор.



 							

	
			

									
						Рубрика: RFC					
					|
				
				
				Комментарии к записи RFC 8175 Dynamic Link Exchange Protocol (DLEP) отключены