RFC 2475 An Architecture for Differentiated Services

Network Working Group                                       S. Blake
Request for Comments: 2475           Torrent Networking Technologies
Category: Informational                                     D. Black
                                                     EMC Corporation
                                                          M. Carlson
                                                    Sun Microsystems
                                                           E. Davies
                                                           Nortel UK
                                                             Z. Wang
                                       Bell Labs Lucent Technologies
                                                            W. Weiss
                                                 Lucent Technologies
                                                       December 1998

Архитектура дифференцированного обслуживания (Diffserv)

An Architecture for Differentiated Services

PDF

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

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

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

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

Тезисы

В этом документе определена архитектура для реализации масштабируемой дифференциации услуг в Internet. Эта архитектура обеспечивает масштабирование за счет агрегирования состояний классификации трафика, которые передаются путем маркировки пакетов IP с использованием поля DS [DSFIELD]. Пакеты классифицируются и маркируются для обеспечения определенной обработки на узлах каждого этапа на пути доставки пакета. Изощренные методы классификации, маркировки, реализации политики, формовки трафика требуются только на границах сетей или хостах. Сетевые ресурсы выделяются для потоков трафика правилами предоставления услуг, которые определяют маркировку и кондиционирование трафика на входе в сеть с поддержкой дифференцированных услуг, а также пересылку трафика внутри такой сети. На основе этого можно построить широкий спектр сетевых услуг.

Оглавление

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

1. Введение

1.1 Обзор

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

Архитектура включает множество функциональных элементов, реализованных на узлах сети, включая небольшой набор аспектов пересылки на каждом этапе, функции классификации трафика и функции кондиционирования трафика, в том числе измерение, маркировку, формование и применение правил. Эта архитектура обеспечивает масштабируемость за счет реализации комплексных функций классификации и кондиционирования исключительно на граничных узлах сетей и выполнения определенных операций на каждом этапе пересылки применительно к агрегатам трафика, маркированным с использованием поля DS в заголовках IPv4 или IPv6 [DSFIELD]. Задается поведение на каждом этапе1 для того, чтобы обеспечить разумную гранулярность распределения буферов и полосы пропускания на каждом узле между конкурирующими потоками трафика. Потоки для каждого приложения и состояние пересылки для каждого заказчика не требуется поддерживать в ядре сети. Поддерживаются различия между:

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

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

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

В параграфе 1.2 определены основные термины, используемые в документе. В параграфе 1.3 перечислены требования, порождаемые этой архитектурой, а параграф 1.4 содержит краткое сравнение с другими моделями дифференциации услуг. В разделе 2 приводится детальное рассмотрение компонент архитектуры. Раздел 3 содержит рекомендации по спецификации поведения на каждом этапе. В разделе 4 обсуждаются вопросы интероперабельности с узлами и сетями, которые не реализуют дифференциации услуг в соответствии с этим документом и [DSFIELD]. В разделе 5 рассматриваются вопросы доставки групповых услуг, а раздел 6 посвящен вопросам безопасности и рассмотрению туннелей.

1.2 Терминология

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

Behavior Aggregate (BA)

Агрегат режима (поведения) DS.

BA classifier

Классификатор, выбирающий пакеты исключительно на основе значения поля DS.

Boundary link — граничное соединение

Канал, соединяющий краевые узлы двух доменов.

Classifier — классификатор

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

DS behavior aggregate — агрегат режима DS

Набор пакетов с одинаковым кодом DS, проходящих по каналу в определенном направлении.

DS boundary node — граничный узел DS

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

DS-capable

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

DS codepoint — код DS

Значение компоненты DSCP поля DS, используемое для выбора PHB.

DS-compliant — поддерживающий DS

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

DS domain — домен DS

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

DS egress node — выходной узел DS

Граничный узел DS, который обслуживает трафик, выходящий из домена DS.

DS ingress node — входной узел DS

Граничный узел DS, который обслуживает трафик, входящий в домен DS.

DS interior node — внутренний узел DS

Узел DS, не являющийся граничным.

DS field — поле DS

Октет TOS в заголовке IPv4 или октет Traffic Class в заголовке IPv6, интерпретируемый в соответствии с определением [DSFIELD]. Биты поля DSCP определяют код DS, а остальные биты в настоящее время не используются.

DS node — узел DS

Поддерживающий DS узел.

DS region — зона DS

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

Downstream DS domain — нисходящий домен DS

Домен DS обрабатывающий нисходящий поток трафика на граничном соединении.

Dropper — отбрасыватель

Устройство, выполняющее отбрасывание пакетов.

Dropping — отбрасывание

Процесс уничтожения пакетов на основе заданных правил (политики).

Legacy node — унаследованный узел

Узел, реализующий IPv4 Precedence в соответствии с [RFC791,RFC1812], но не поддерживающий DS.

Marker — маркировщик

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

Marking — маркировка

Процесс установки кода DS в пакетах в соответствии с заданными правилами; используются также термины pre-marking (предварительная маркировка), re-marking (перемаркировка).

Mechanism — механизм

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

Meter — измеритель

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

Metering — измерение

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

Microflow — микропоток

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

MF Classifier — классификатор MF

Многокомпонентный (MF2) классификатор, который выбирает пакеты на основе содержимого некого произвольного числа полей заголовков; обычно набор полей включает ту или иную комбинацию адресов и номеров портов отправителя и получателя, поле DS, идентификатор протокола.

Per-Hop-Behavior (PHB) — режим поэтапной обработки

Наблюдаемое извне поведение пересылки пакетов узлом DS по отношению агрегату BA.

PHB group — группа PHB

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

Policing — реализация политики

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

Pre-mark — предварительная маркировка

Установка кода DS для пакета до его входа в нисходящий домен DS.

Provider DS domain — DS-домен провайдера

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

Re-mark — перемаркировка

Изменение кода DS для пакета, обычно выполняемое маркировщиком в соответствии с TCA.

Service — сервис, обслуживание

Интегральная обработка трафика определенного подмножества заказчиков (сквозная или в домене DS).

Service Level Agreement (SLA) — соглашение об уровне обслуживания

Сервисный контракт между заказчиком и сервис-провайдером, задающий услуги по пересылке пакетов, предоставляемые заказчику. Заказчиком может служить конечный пользователь (домен-отправитель) или другой домен DS (восходящий3 домен). SLA может включать правила кондиционирования трафика, которые полностью или частично задают TCA.

Service Provisioning Policy — правила обслуживания

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

Shaper — формовщик

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

Shaping — формовка

Процесс внесения задержки для пакетов в потоке трафика с целью реализации определенного профиля трафика.

Source domain — домен-отправитель

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

Traffic conditioner — кондиционер трафика

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

Traffic conditioning — кондиционирование трафика

Функции управления, выполняемые для реализации правил, указанных TCA, включая измерение, маркировку, формовку и реализацию политики.

Traffic Conditioning Agreement (TCA) — соглашение о кондиционировании трафика

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

Traffic profile — профиль трафика

Описание временных характеристик потока трафика (таких, как скорость и пиковая скорость).

Traffic stream — поток трафика

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

Upstream DS domain — восходящий домен DS

Домен DS обрабатывающий восходящий поток трафика на граничном канале.

1.3 Требования

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

Ниже перечислены идентифицированные требования, решаемые данной архитектурой:

  • следует обеспечивать аккомодацию к широкому спектру услуг и правил их предоставления в масштабах группы сетей или в сквозном режиме;
  • следует разрешать «отвязывание» сервиса от конкретного приложения;
  • следует работать с существующими приложениями, не требуя изменения API или программ хостов (предполагается развертывание нужных классификаторов, маркировщиков и других средств кондиционирования трафика);
  • следует отвязать функции кондиционирования трафика и предоставления услуг от режимов пересылки, реализованных в узлах ядра сети;
  • следует обеспечить независимость от поэтапной (hop-by-hop) сигнализации приложений;
  • следует требовать только минимальный набор режимов пересылки, чтобы сложность его реализации не доминировала над стоимостью сетевых устройств и не возникало «пробок» в скоростных системах будущего;
  • следует избегать поддержки состояний для отдельных микропотоков и отдельных заказчиков в узлах ядра сети;
  • с ядре сети следует использовать только агрегированные классификационные состояния;
  • в ядре сети следует использовать простые реализации классификаторов пакетов (классификаторов BA);
  • следует поддерживать разумную интероперабельность с узлами, не поддерживающими DS;
  • следует поддерживать постепенное развертывание.

1.4 Сравнение с другими моделями

Описываемая в этом документе архитектура дифференцированного обслуживания может противоречить другим моделям дифференциации услуг. Мы классифицируем эти альтернативные модели по нескольким категориям — маркировка относительного приоритета, маркировка сервиса, коммутация меток, интегрированные службы/RSVP и статическая классификация для каждого этапа пересылки.

Примерами маркировки относительного приоритета могут служить маркировка IPv4 Precedence [RFC791], 802.5 Token Ring [TR] и принятая по умолчанию интерпретация классов трафика 802.1p [802.1p]. В этой модели приложения, хосты или узлы-посредники выбирают относительный уровень приоритета или «предпочтения» для пакета (например, приоритет по задержке или отбрасыванию), а сетевые узлы на пути передачи применяют соответствующий значению приоритета в поле заголовка режим пересылки. Наша архитектура может задавать роль и важность граничных узлов и кондиционеров трафика, благодаря этому наша модель обеспечивает более общий подход к поэтапному режиму пересылки, нежели относительный приоритет для задержки или отбрасывания.

Примером модели маркировки услуг является IPv4 TOS в соответствии с определением [RFC1349]. В этом примере каждый пакет маркируется запросом «типа обслуживания», который принимать значения «минимизировать задержку», «максимизировать пропускную способность», «максимизировать надежность» или «минимизировать стоимость». Узлы сети могут выбирать путь маршрутизации или режим пересылки, который подходит для запрошенного типа обслуживания. Эта модель имеет тонкие отличия от нашей архитектуры. Отметим, что мы не описываем использование поля DS в качестве входной информации для выбора маршрута. Маркировка TOS, определенная в [RFC1349], является весьма общей и не охватывает весь диапазон возможной семантики обслуживания. Более того, с каждым пакетом связывается запрос на обслуживание, а семантика некоторых услуг может зависеть от агрегированного режима пересылки последовательности пакетов. Модель маркировки услуг достаточно сложно приспособить к будущему росту числа и диапазона услуг (поскольку пространство кодов достаточно мало) и эта модель включает настройку конфигурации ассоциаций «TOS->режим пересылки» на каждом узле ядра сети. Стандартизация маркировки услуг предполагает стандартизацию предложений услуг, которая выходит за пределы компетентности IETF. Отметим, что при распределении пространства кодов DS, часть кодов зарезервирована для обеспечения возможности локального управления кодами, позволяющего провайдерам поддерживать локальную семантику маркировки услуг [DSFIELD].

Примеры модели коммутации меток (или виртуальных устройств) включают Frame Relay, ATM и MPLS [FRELAY, ATM]. В этой модели поддерживается состояние пересылки и управления трафиком или QoS для потоков трафика на каждом интервале пути через сеть. Агрегаты трафика различной гранулярности ассоциируются с путем коммутации меток на входном узле, а пакеты/ячейки в каждом пути коммутации меток маркируются меткой пересылки, которая используется для поиска следующего интервала, а также режима пересылки и заменяется на каждом этапе пересылки. Эта модель обеспечивает тонкую гранулярность распределения ресурсов для потоков трафика, поскольку значения меток не имеют глобальной значимости и важны только для одного канала. Следовательно, можно резервировать ресурсы для агрегирования пакетов/ячеек, принятых на канале с определенной меткой, а семантика коммутации меток определяет выбор следующего интервала, позволяя передавать потоки трафика через специально созданные для них сетевые пути. Такое улучшение гранулярности связано с расходами на выполнение дополнительных требований по управлению и настройке для организации и поддержке путей коммутации меток. В дополнение к этому количество состояний пересылки, поддерживаемых на каждом узле, растет пропорционально числу краевых узлов сети в лучшем случае (в предположении путей коммутации меток multipoint-to-point) и пропорционально квадрату числа краевых узлов в худшем случае, когда обеспечиваются пути коммутации меток «от края до края» с гарантированными ресурсами.

Модель интегрированных услуг/RSVP4 основана на традиционной пересылке дейтаграмм по умолчанию, но позволяет отправителям и получателям обмениваться сигнальными сообщениями, которые позволяют организовать дополнительную классификацию пакетов и состояние пересылки на каждом узле между ними [RFC1633, RSVP]. В отсутствии агрегирования состояний их число на каждом узле растет пропорционально числу одновременных резервирований, которое для скоростных каналов может быть очень большим. Эта модель также требует от приложений поддержки протокола RSVP. Для агрегирования состояний интегрированных услуг/RSVP в ядре сети могут использоваться механизмы дифференциации обслуживания [Bernet].

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

Хотя мы противопоставили альтернативные модели и дифференциацию обслуживания, следует отметить, что эти методы могут использоваться для расширения режимов и семантики дифференцированного обслуживания в коммутируемой инфраструктуре канального уровня (например, ЛВС 802.1p, магистрали Frame Relay/ATM), соединяющей узлы DS, а также в том случае, когда в качестве внутридоменной технологии может использоваться MPLS. Ограничения, вносимые конкретной технологией канального уровня в отдельной зоне домена DS (или в сети, обеспечивающей доступ к доменам DS), могут загрублять дифференциацию обслуживания. В зависимости от отображения PHB на различные услуги канального уровня и способа распределения пакетов по ограниченному набору классов приоритета (или виртуальных устройств различных категорий и производительности), поддерживаться могут все или часть PHB (некоторые могут оказаться нежелательными).

2. Архитектурная модель дифференциации услуг

Архитектура дифференцированного обслуживания основана на простой модели, где трафик классифицируется на входе в сеть и, возможно, кондиционируется на границах сети; классифицированный трафик относится к тому или иному агрегату режима обработки. Каждый агрегат идентифицируется одним кодом DS. Внутри ядра сети пакеты пересылаются в соответствии с заданным для этапа режимом, связанным с кодом DS. В этом разделе обсуждаются компоненты зоны дифференцированного обслуживания, функции классификации и кондиционирования трафика, а также вопросы дифференцированного обслуживания, реализуемого через комбинацию кондиционирования трафика и пересылки на основе PHB.

2.1 Домен дифференцированных услуг

Домен DS представляет собой связное множество узлов DS, которые работают с общим набором правил предоставления услуг, и набором групп PHB, реализованных на каждом узле. Домен DS имеет хорошо определенные границы, состоящие из граничных узлов DS, которые классифицируют и, возможно, кондиционируют входящий трафик для обеспечения проходящим через домен пакетам корректной маркировки для выбора PHB из групп PHB, поддерживаемых в домене. Узлы в домене DS выбирают режим пересылки для пакетов на основе кода DS, отображая этот код на один из поддерживаемых режимов PHB с использованием рекомендованного отображения код->PHB или локально управляемого отображения [DSFIELD]. Включение не поддерживающих DS узлов в домен DS может приводить к непредсказуемому изменению производительности и осложнять возможность выполнения сервисных соглашений (SLA).

Домен DS состоит из одной или множества сетей с общим администрированием (например, внутренняя сеть организации или сеть ISP). Администрация домена отвечает за обеспечение достаточных ресурсов и/или их резервирование для обеспечения SLA, предлагаемых доменом.

2.1.1 Граничные и внутренние узлы DS

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

Как граничные, так и внутренние узлы DS должны быть способны применять подходящий режим PHB к пакетам на основе кода DS; в противном случае поведение может стать непредсказуемым. В дополнение от граничных узлов DS может требоваться выполнение функций кондиционирования трафика в соответствии с соглашением о кондиционировании (TCA) между доменом DS и доменами-партнерами, с которыми он соединен (см. параграф 2.3.3).

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

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

2.1.2 Входные и выходные узлы DS

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

2.2 Зона дифференцированного обслуживания

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

Домены DS в зоне DS могут поддерживать различные группы PHB внутри себя и разные отображения код->PHB. Однако для того, чтобы разрешить услуги, которые могут предоставляться через несколько доменов, партнерские домены DS должны организовать партнерские SLA, которые определяют (явно или неявно) TCA, задающие кондиционирование трафика из одного домена DS в другой на границе между двумя доменами DS.

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

2.3 Классификация и кондиционирование трафика

Дифференцированные услуги предоставляются через границу домена DS путем организации SLA между восходящей (upstream) сетью и нисходящим (downstream) доменом DS. SLA может задавать правила классификации и перемаркировки трафика, а также профили трафика и действия для потоков трафика, который относится или не относится к профилю (см. параграф 2.3.2). TCA между доменами организуется (явно или неявно) на основе таких SLA.

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

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

2.3.1 Классификаторы

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

Классификаторы служат для «направления» пакетов, соответствующих определенному правилу, элементу кондиционирования трафика для последующей обработки. Классификаторы должны настраиваться с помощью той или иной процедуры управления в соответствии с подходящим TCA.

Классификаторам следует проверять подлинность информации, используемой для выбора пакетов (см. раздел 6).

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

2.3.2 Профили трафика

Профиль трафика задает временные параметры потока трафика, выбранного классификатором. Это обеспечивает правила для определения соответствия конкретного пакета данному профилю. Например, профиль на основе token bucket9 может иметь вид:

codepoint=X, use token-bucket r, b

Такой профиль показывает, что все пакеты с кодом DS = X, следует сравнивать с уровнем потока r и размером выбросов трафика b. В этом примере профилю не соответствуют пакеты из потока трафика, принимаемые в те моменты, когда в корзине не остается маркеров. Концепцию можно расширить, используя более двух уровней. Например, можно определить и реализовать профиль с множеством уровней маркирования.

К пакетам, соответствующим и не соответствующим профилю, могут применяться различные операции или включаться те или иные механизмы учета. Соответствующим профилю пакетам может разрешаться вход в домен DS без дальнейшего кондиционирования или, наоборот, их код DS может быть изменен. Последнее происходит в тех случаях, когда для DS изначально установлено отличное от принятого по умолчанию значение [DSFIELD], или пакеты входят в домен DS, использующий другую группу PHB или иное отображение код->PHB для этого потока трафика. Пакеты, не соответствующие профилю, могут помещаться в очередь, пока они не войдут в профиль (формовка), отбрасываться (политика), маркироваться новым кодом (перемаркировка) или пересылаться без изменений, но с включением некой процедуры учета. Не соответствующие профилю пакеты могут отображаться в один или несколько агрегатов поведения, которые являются «подчиненными» в плане скорости пересылки по отношению к BA, куда отображаются соответствующие профилю пакеты.

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

2.3.3 Кондиционеры трафика

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

                       +----------+
                       |          |--------------------+
                   +-->|Измеритель|                    |
                   |   |          |---+                |
                   |   +----------+   |                |
                   |                  V                V
             +-------------+      +--------+      +---------+
             |             |      |        |      | Формов./|
пакеты =====>|Классификатор|=====>| Маркер |=====>|Отбрасыв.|=====>
             |             |      |        |      |         |
             +-------------+      +--------+      +---------+

Рисунок 1: Логическое представление классификатора пакетов и кондиционера трафика

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

Рисунок 1 показывает блок-схему классификатора и кондиционера трафика. Отметим, что кондиционер трафика может не включать все 4 элемента. Например, в тех случаях, когда профили трафика не используются, пакеты могут проходить только через классификатор и измеритель.

2.3.3.1 Измерители

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

2.3.3.2 Маркировщики

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

2.3.3.3 Формовщики

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

2.3.3.4 Отбрасыватели

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

2.3.4 Расположение кондиционеров трафика и классификаторов MF

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

2.3.4.1 Внутри исходного домена

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

Рассмотрим пример компании, в соответствии с политикой которой пакетам от CEO11 следует присваивать высший приоритет. Хост CEO может маркировать поле DS всех исходящих пакетов значением DS, показывающим «высший приоритет». Кроме того, первый маршрутизатор, с которым соединен хост CEO, может классифицировать трафик и маркировать пакеты CEO корректным кодом DS. Такой трафик с высоким приоритетом также может быть кондиционирован неподалеку от источника так, чтобы ограничить уровень трафика с высшим приоритетом, пересылаемого от конкретного источника.

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

Поскольку маркировка пакетов может осуществляться на множестве узлов, исходный домен DS отвечает за то, что агрегированный трафик в направлении домена DS его провайдера соответствует TCA. Дополнительные механизмы распределения ресурсов типа брокеров полосы или RSVP могут использоваться для динамического выпределения ресурсов отдельному агрегату поведения DS в сети провайдера [2BIT, Bernet]. Граничному узлу исходного домена следует также осуществлять мониторинг соответствия TCA, этот узел может при необходимости выполнять перемаркировку и формовку или применять для пакетов правила политики.

2.3.4.2 На границе домена DS

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

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

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

2.3.4.3 В доменах, не поддерживающих DS

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

2.3.4.4 На внутренних узлах DS

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

2.4 Поведение на этапе

Поведение на этапе (PHB12) представляет собой описание наблюдаемого извне режима пересылки узла DS, применяемое к конкретному агрегату поведения DS. «Режим пересылки» представляет собой базовую концепцию в этом контексте. Например, в ситуации, когда только один агрегат поведения занимает канал, наблюдаемый режим пересылки (т. е., потери, задержки и их вариации) будет зачастую зависеть только от относительной загрузки канала (в предположении, что режим основан на снижающей объем работы дисциплине планирования). Существенные различия в поведении наблюдаются для тех случаев, когда множество агрегатов поведения полностью используют ресурсы буферизации и полосы на узле. PHB представляет собой способ, посредством которого узел выделяет ресурсы для агрегатов поведения, и располагается поверх базовых поэтапных механизмов распределения ресурсов, которые могут быть полезны для поддержки дифференцированного обслуживания.

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

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

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

Как описано в документе [DSFIELD], PHB выбирается на узле путем отображения кода DS в принятом пакете. Стандартизованные PHB имеют рекомендованные значения кода. Однако общее пространство кодов больше, нежели пространство, доступное для рекомендованных значений стандартизованных PHB и [DSFIELD] оставляет возможность для локально настраиваемых отображений. Таблица отображений код->PHB может содержать отображения как 1->1, так и N->1. Все коды должны быть отображены на тот или иной PHB; в отсутствии какой-либо локальной политики коды, которые не отображаются на стандартизованные PHB, в соответствии со спецификацией PHB следует отображать на Default PHB.

2.5 Распределение сетевых ресурсов

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

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

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

3. Рекомендации по заданию поведения на этапе

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

G.1: Стандарт PHB должен задавать рекомендуемое значение кода DS, выбранное из пространства, зарезервированного для стандартных отображений [DSFIELD]. Рекомендуемые коды распределяются IANA. Предложение PHB может рекомендовать временный код из пространства EXP/LU для использования в междоменных экспериментах. Определение PHB для пакетов не должно требовать использования полей заголовка, отличных от DS.

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

G.3: В спецификации группы PHB следует указывать число отдельных PHB в группе. При задании множества PHB следует четко описать взаимодействие между всеми PHB в группе и ограничения при таком взаимодействии. В качестве примера укажем, что спецификация должна рассматривать возможность повышения вероятности изменения порядка следования пакетов в микропотоке в результате маркировки этих пакетов для разных PHB в группе.

G.4: Когда корректное функционирование группы PHB зависит от ограничений (таких, как ограничения в обеспечении), в определение PHB следует включать описание поведения в случае нарушения таких ограничений. Более того, если нужны такие действия, как отбрасывание пакетов или смена порядка, эти действия следует оговаривать явно.

G.5: Группа PHB может быть специфицирована для локального использования в домене с целью обеспечения специфической для данного домена функциональности или услуг. В этом случае спецификация PHB полезна для предоставления производителям согласованного определения группы PHB. Однако любые группы PHB, определенные для локального применения, не следует стандартизовать, что не препятствует их публикации в виде информационных RFC. Напротив, группы PHB, предназначенные для общего пользования, должны строго следовать процессу стандартизации. Следовательно, все предложения PHB должны содержать сведения о локальном или глобальном использовании группы.

Понятно, что группы PHB могут разрабатываться для обеспечения услуг между хостами, краевыми узлами сетей WAN13 и/или краевыми узлами доменов. Термин «сквозной» (end-to-end) в определении PHB следует трактовать как «между хостами» (host-to-host).

Группы PHB могут определяться и развертываться локально внутри доменов для экспериментов или в рабочем режиме. К таким группам не предъявляется требование публикации документов, но для этих групп PHB следует использовать коды DS из пулов EXP/LU, определенных в [DSFIELD].

G.6: Возможны случаи, когда пакеты, помеченные для PHB в группе, могут быть перемаркированы для выбора другого PHB в той же группе, Такая перемаркировка может осуществляться внутри домена или для пакетов, проходящих через границу домена. Обычно замена PHB обусловлена одной из трех причин:

  1. Коды, связанные с группой PHB, предназначены для передачи информации о состоянии сети.
  2. Существуют ситуации, когда от PHB требуется повышение или снижение уровня приоритета для пакета (это предполагает некое ранжирование PHB внутри группы).
  3. Граница между доменами не покрывается SLA. К этом случае код/PHB для выбора при прохождении через пограничный канал определяется локальной политикой восходящего домена.

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

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

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

G.8: Очевидно, что процесс спецификации групп PHB является инкрементным по своей природе. Когда предлагается новая группа PHB, следует документировать ее понятные взаимодействия с ранее определенными группами PHB. Создаваемая группа PHB может быть совсем новой или являться расширением какой-либо из существующих групп PHB. Если группа PHB полностью независима от всех или некоторых существующих спецификаций PHB, в спецификацию такой группы PHB следует включать раздел, описывающий сосуществование новой группы PHB с ранее стандартизованными группами PHB. Например, такой раздел может указывать возможность изменения порядка следования пакетов в микропотоке для пакетов, промаркированных кодами, которые связаны с двумя разными группами PHB. Если одновременная работа двух (или более) разных групп PHB на одном узле невозможна или может причинять вред, этот факт следует указывать в спецификации. Если одновременная работа двух (или более) разных групп PHB требует некого специфического режима, когда пакеты, маркированные для PHB из этих разных групп будут одновременно обрабатываться узлом, такое поведение должно быть отражено в спецификации.

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

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

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

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

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

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

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

G.13: В каждую спецификацию PHB рекомендуется включать приложение, содержащее руководство по выбору PHB для пакетов, которые пересылаются в домены, не поддерживающие данную группу PHB.

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

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

4. Взаимодействие с узлами, не поддерживающими DS

Определим узел, не поддерживающий дифференциацию услуг (non-DS-compliant), как любой узел, который не интерпретирует поле DS в соответствии с [DSFIELD] и/или не поддерживает некоторые или все стандартизованные PHB (или PHB используемые в определенном домене DS). Такое поведение может быть результатом настройки узла или отсутствия поддержки соответствующих функций. Определим унаследованный узел, как специальный случай не поддерживающего DS узла, который реализует функции классификации и пересылки IPv4 Precedence в соответствии с [RFC791, RFC1812], но не соответствует DS. Значения предпочтений в октете IPv4 TOS осознанно сделаны совместимыми со значениями кодов селекторов класса, определенными в [DSFIELD], а режим рассылки с использованием предпочтений, определенный в [RFC791, RFC1812], совместим с требованиями Class Selector PHB, определенными в [DSFIELD]. Ключевым различием между унаследованным узлом и узлом, поддерживающим DS, является то, что унаследованный узел может интерпретировать или не интерпретировать биты 3-6 октета TOS (биты DTRC), как определено в [RFC1349]; на практике такой узел не будет интерпретировать эти биты в соответствии с [DSFIELD]. Мы предполагаем, что использование маркировки TOS, определенной в [RFC1349], в настоящее время не принято. Узлы, не совместимые с DS и не относящиеся к категории унаследованных, могут вести себя непредсказуемо по отношению к пакетам с отличными от нуля кодами DS14.

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

Рассмотрим два случая. Первый относится к использованию не поддерживающих DS узлов в доменах DS. Отметим, что пересылка с использованием PHB полезна, прежде всего, для контролируемого распределения дефицитных ресурсов узла или каналов. На высокоскоростных, слабо загруженных каналах максимальная задержка, вариации задержки и уровень потери пакетов пренебрежимо малы и использование не поддерживающего DS узла на восходящем конце такого канала может и не приводить к деградации сервиса. В более реалистичных условиях отсутствие пересылки с использованием PHB на узле может приводить к невозможности обеспечения малых задержек, низкого уровня потерь или требуемой полосы для проходящих через узел путей. Однако использование унаследованного узла может быть приемлемым вариантом, если домен DS ограничивается использованием только кодов селекторов класса, определенных в [DSFIELD], и предполагается, что конкретная реализация пересылки по предпочтениям на унаследованном узле обеспечивает режим пересылки, совместимый с услугами, предлагаемыми для проходящего через этот узел пути. Отметим, что важно ограничить использование кодов исключительно значениями Class Selector, поскольку унаследованный узел не обязан интерпретировать биты 3-5 в соответствии с [RFC1349], а это может вести к непредсказуемому поведению.

Второй случай относится к поведению сервиса, проходящего через домен, который не поддерживает DS. Для простоты аргументации предполагается, что не поддерживающий DS домен, не реализует функций кондиционирования трафика на граничных узлах. Следовательно, даже при условии присутствия внутри домена унаследованных узлов или узлов, поддерживающих DS, отсутствие правил, применяемых к трафику на границе домена, будет ограничивать возможности предоставления некоторых типов обслуживания через такой домен. Домен DS и домен, не поддерживающий DS, могут согласовать условия маркировки трафика, выходящего из домена DS, до входа в домен, который не поддерживает DS. Мониторинг выполнения заключенного соглашения может осуществляться путем выборки трафика взамен жесткого его кондиционирования. Когда известно о том, что не поддерживающий DS домен состоит из унаследованных узлов, восходящий домен DS может перемаркировать трафик дифференцированного обслуживания с использованием одного или нескольких кодов Class Selector. Когда информации о возможностях управления трафиком в нисходящем домене нет и отсутствует соглашение, выходной узел домена DS может принять решение о перемаркировке кодов DS с использованием нулевого значения в предположении, что не поддерживающий DS домен будет пытаться обеспечить однородное обслуживание пакетов с использованием доступных возможностей (best-effort).

Если не поддерживающий DS домен является партнером домена DS, трафик из домена, не поддерживающего DS, следует кондиционировать на входном узле домена DS в соответствии с подходящим SLA или правилами.

5. Вопросы групповой адресации

Использование дифференцированного обслуживания для трафика с групповой адресацией порождает множество вопросов. Во-первых, пакеты с групповой адресацией, которые входят в домен DS, могут на входном узле распределяться по множеству путей через некоторые сегменты домена в результате репликации пакетов с групповыми адресами. В таких случаях может потребляться больше сетевых ресурсов, нежели при обработке индивидуальных пакетов. Когда группы multicast являются динамическими, сложно заранее предсказать объем потребных сетевых ресурсов для обслуживания группового трафика из восходящей сети в ту или иную группу. В результате такой неопределенности может осложняться обеспечение гарантий обслуживания для отправителей группового трафика. Более того, может потребоваться резервирование кодов и PHB для исключительного использования с групповым трафиком, чтобы обеспечить изоляцию ресурсов от группового трафика.

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

6. Вопросы безопасности и туннелирования

В этом разделе рассматриваются вопросы безопасности, возникающие в связи с введением дифференцированного обслуживания, прежде всего, потенциальные атаки на службы (DoS) и потенциальные возможности несанкционированного обслуживания трафика (параграф 6.1). В дополнение к этому рассматривается дифференцированное обслуживание в присутствии IPsec (параграф 6.2) и требования к аудиту (параграф 6.3). Рассматриваются вопросы, связанные с использованием туннелей (как IPsec, так и иных).

6.1 Несанкционированное обслуживание и атаки на службы

Основной задачей дифференциации обслуживания является обеспечение возможности предоставления потокам трафика разного уровня сервиса в одной сетевой инфраструктуре. Для достижения результата могут использоваться различные методы управления ресурсами, но конечный результат должен заключаться в том, что обслуживание одних пакетов будет отличаться от обслуживания других (например, будет лучше). Отображение сетевого трафика на соответствующий режим, приводящий к иному (лучше или хуже) обслуживанию, задается, прежде всего, значением поля DS и, следовательно, злоумышленник может добиться улучшения обслуживания путем изменения поля DS для отображения трафика на режим, используемый для обеспечения лучшего обслуживания, или вставки пакетов с соответствующим значением поля DS. С учетом ограниченности ресурсов такой обман может служить для организации атак на службы, когда изменение или вставка пакетов ведет к исчерпанию ресурсов, доступных для пересылки других потоков трафика. Защита от таких «краж» и DoS-атак включает средства кондиционирования трафика на граничных узлах DS в сочетании с обеспечением защиты и целостности сетевой инфраструктуры домена DS.

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

Как политика обслуживания в домене, так и TCA могут требовать смены на входных узлах кода DS для некоторых пакетов (например, входной маршрутизатор может устанавливать для пользовательского трафика код DS в соответствии с подходящим SLA). Входные узлы должны кондиционировать весь остальной входящий трафик для обеспечения приемлемости кодов DS; пакеты с неприемлемыми кодами должны отбрасываться или значение кода DS должно меняться на приемлемое до пересылки пакета. Например, входной узел, получая трафик от домена, для которого нет соглашения об улучшенном обслуживании, может сбрасывать код DS в значение, принятое для Default PHB [DSFIELD]15. Для разрешения использования некоторых кодов DS (например, соответствующих улучшенному обслуживанию) может потребоваться идентификация трафика, которая может быть выполнена техническими (например, IPsec) и/или иными (например, подключение входного канала к единственному заказчику) средствами.

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

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

Любой канал, для которого невозможно обеспечить адекватную защиту от изменения кодов DS или внедрения несанкционированного трафика, следует трактовать, как граничный канал (и, следовательно, весь входящий через этот канал трафик должен обрабатываться как на входном узле домена). Определение «адекватной защиты» задается локальной политикой безопасности и может включать определение рисков и последствий, связанных с изменением кодов DS, которые не перекрываются дополнительными мерами по обеспечению безопасности для данного канала. Уровень защиты канала можно дополнительно повысить за счет контроля доступа на физическом уровне и/или программными средствами (типа организации туннелей), обеспечивающими целостность пакетов.

6.2 Взаимодействие с IPsec и туннелями

Протокол IPsec, как указано в [ESP, AH], не включает операций с полем DS заголовков IP в криптографические преобразования (в туннельном режиме поле DS внешнего заголовка IP не шифруется). Следовательно, изменение поля DS в сети не оказывает влияния на сквозную защиту IPsec, поскольку такое изменение не способно дать отрицательный результат при проверке целостности IPsec. В результате IPsec не обеспечивает какой-либо защиты от злонамеренного изменения поля DS (т. е., перехвата и изменения с участием человека — MITM), поскольку такое изменение не оказывает влияния на уровень сквозной защиты IPsec. В некоторых средах возможность изменения поля DS без влияния на целостность данных IPsec может позволить создание скрытого канала; если требуется предотвратить создание таких каналов или снизить их полосу, домены DS следует настраивать так, чтобы требуемая обработка (например, установка одного значения для всех полей DS в чувствительном трафике) могла выполняться на выходных узлах DS, где трафик выходит из защищенных доменов.

Туннельный режим IPsec обеспечивает защиту для полей DS инкапсулированных заголовков IP. Пакет IPsec в туннельном режиме включает два заголовка IP — внешний заголовок, подставляемый на входе туннеля, и внутренний (инкапсулированный) заголовок от инициатора пакета. Когда туннель IPsec проходит (полностью или частично) через сети с дифференциацией услуг, промежуточные узлы оперируют с полем DS внешнего заголовка. На выходе из туннеля IPsec внешние заголовки удаляются и пакет пересылается (если нужно) с использованием внутреннего заголовка. Если внутренний заголовок IP не обрабатывается входным узлом DS при выходе из туннеля в домен DS, выходной узел туннеля является входным узлом DS для выходящего из туннеля трафика и, следовательно, для него должно осуществляться соответствующее кондиционирование (см. параграф 6.1). Если обработка IPsec включает достаточно строгую криптографическую проверку целостности инкапсулированного пакета (достаточность определяется локальной политикой безопасности), выходной узел туннеля может без опасений предполагать, что поле DS во внутреннем заголовке не изменилось по сравнению со значением на входе в туннель. Это позволяет выходному узлу туннеля, находящемуся в одном домене DS со входным узлом туннеля, без опасений относиться к пакетам, прошедшим такую проверку целостности, как к пакетам, полученным от узла в том же домене DS, избавляя входной узел домена DS от необходимости кондиционирования трафика, которое требуется в противном случае. Важным следствием этого является то, что незащищенные каналы, являющиеся внутренними по отношению к домену DS, могут быть защищены с помощью достаточно надежного туннеля IPsec.

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

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

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

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

6.3 Аудит

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

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

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

Этот документ основан на ранних работах Steven Blake, David Clark, Ed Ellesson, Paul Ferguson, Juha Heinanen, Van Jacobson, Kalevi Kilkki, Kathleen Nichols, Walter Weiss, John Wroclawski и Lixia Zhang.

Авторы выражают свою признательность за полезные комментарии и предложения Kathleen Nichols, Brian Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng, Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, Borje Ohlman, Alessio Casati, Scott Brim, Curtis Villamizar, Hamid Ould-Brahi, Andrew Smith, John Renwick, Werner Almesberger, Alan O’Neill, James Fu и Bob Braden.

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

[802.1p] ISO/IEC Final CD 15802-3 Information technology — Tele-communications and information exchange between systems — Local and metropolitan area networks — Common specifications — Part 3: Media Access Control (MAC) bridges, (current draft available as IEEE P802.1D/D15)16.

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

[ATM] ATM Traffic Management Specification Version 4.0 <af-tm-0056.000>18, ATM Forum, April 1996.

[Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. Nichols, and M. Speer, «A Framework for Use of RSVP with Diff-serv Networks», Work in Progress19.

[DSFIELD] 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, December 1998.

[EXPLICIT] D. Clark and W. Fang, «Explicit Allocation of Best Effort Packet Delivery Service», IEEE/ACM Trans. on Networking, vol. 6, no. 4, August 1998, pp. 362-373.

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

[FRELAY] ANSI T1S1, «DSSI Core Aspects of Frame Rely», March 1990.

[RFC791] Postel, J., Editor, «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1349] Almquist, P., «Type of Service in the Internet Protocol Suite», RFC 1349, July 1992.

[RFC1633] Braden, R., Clark, D. and S. Shenker, «Integrated Services in the Internet Architecture: An Overview», RFC 1633, July 1994.

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

[RSVP] Braden, B., Zhang, L., Berson S., Herzog, S. and S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, September 1997.

[2BIT] K. Nichols, V. Jacobson, and L. Zhang, «A Two-bit Differentiated Services Architecture for the Internet», ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997.

[TR] ISO/IEC 8802-5 Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Common specifications — Part 5: Token Ring Access Method and Physical Layer Specifications22, (also ANSI/IEEE Std 802.5-1995), 1995.

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

Steven Blake

Torrent Networking Technologies

3000 Aerial Center, Suite 140

Morrisville, NC 27560

Phone: +1-919-468-8466 x232

EMail: slblake@torrentnet.com
David L. Black

EMC Corporation

35 Parkwood Drive

Hopkinton, MA 01748

Phone: +1-508-435-1000 x76140

EMail: black_david@emc.com
Mark A. Carlson

Sun Microsystems, Inc.

2990 Center Green Court South

Boulder, CO 80301

Phone: +1-303-448-0048 x115

EMail: mark.carlson@sun.com
Elwyn Davies

Nortel UK

London Road

Harlow, Essex CM17 9NA, UK

Phone: +44-1279-405498

EMail: elwynd@nortel.co.uk
Zheng Wang

Bell Labs Lucent Technologies

101 Crawfords Corner Road

Holmdel, NJ 07733

EMail: zhwang@bell-labs.com
Walter Weiss

Lucent Technologies

300 Baker Avenue, Suite 100

Concord, MA 01742-2168

EMail: wweiss@lucent.com


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

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

nmalykh@gmail.com

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

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

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

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

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

1Per-hop behavior.

2Multi-field — по множеству полей.

3Upstream domain.

4Integrated Services/RSVP.

5Hop-by-hop.

6В оригинале — DS Region. Прим. перев.

7Behavior Aggregate — агрегат поведения.

8Multi-Field — по множеству полей.

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

10Policing.

11Chief Executive Officer — исполнительный директор.

12Per-hop behavior.

13Wide Area Network — распределенная (глобальная) сеть. Прим. перев.

14См. RFC 3260. Прим. перев.

15См. обсуждение в разделе 6 RFC 3260. Прим. перев.

16В настоящее время это является частью стандарта IEEE 802.1D, доступного на сайте http://standards.ieee.org/getieee802/download/802.1D-2004.pdf. Прим. перев.

17В настоящее время этот документ устарел и земенен RFC 4302. Прим. перев.

18Документ доступен по ссылке http://www.ipmplsforum.org/ftp/pub/approved-specs/af-tm-0056.000.pdf. Прим. перев.

19В настоящее время работа завершена и опублибликована в RFC 2998. Прим. перев.

21В настоящее время этот документ устарел и земенен RFC 4303 и RFC 4305. Прим. перев.

22Документ доступен по ссылке http://standards.ieee.org/getieee802/download/802.5-1998.pdf. Прим. перев.




RFC 2476 Message Submission

Network Working Group                                     R. Gellens
Request for Comments: 2476                                  QUALCOMM
Category: Standards Track                                 J. Klensin
                                                                 MCI
                                                       December 1998

Подача сообщений

Message Submission

PDF

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

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

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

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

Оглавление

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

1. Тезисы

SMTP был определен как протокол пересылки (transfer) сообщений, т. е., он способен маршрутизировать (если нужно) и доставлять почтовые сообщения. Не предполагается, что агенты пересылки сообщений (MTA1) изменяют текст этих сообщений за исключением добавления ‘Received’, ‘Return-Path’ и других полей заголовков в соответствии с требованиями [SMTP-MTA].

Однако в настоящее время SMTP широко используется в качестве протокола приема сообщений от пользователей2, т. е., предоставляют почтовым агентам (MUA3) возможность отправки новых сообщений в сеть маршрутизации MTA. Процесс, принимающий пользовательские сообщения от MUA, называют агентом подачи сообщений (MSA4).

Подаваемые сообщения могут быть в некоторых случаях завершенными (finished или complete), а в других — незавершенными (unfinished или incomplete). Незавершенные сообщения требуется дополнить в соответствии с требованиями [MESSAGE-FORMAT] и более поздних документов. Например, в сообщении может не быть корректного поля ‘Date’ или домен может не быть указан полным именем. В некоторых случаях агент MUA может оказаться неспособным генерировать завершенные сообщения (например, при отсутствии данных о часовом поясе). Даже в тех случаях, когда подается полное сообщение, локальная политика сайта может требовать проверки или изменения текста сообщения. Такие дополнения и изменения приносят вред, если их производить на “нисходящих” (downstream) MTA — т. е., на MTA после использованного для подачи сообщения агента MTA – и в общем случае выходят за пределы стандартных функций агента MTA.

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

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

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

Публичные комментарии следует слать по адресу списка рассылки IETF Submit <ietf-submit@imc.org>. Для подписки на рассылку следует отправить сообщение с текстом SUBSCRIBE по адресу <ietf-submit-request@imc.org>. Частные комментарии можно напрямую отправлять автору.

2. Сведения о документе

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

Fully-Qualified – полное имя

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

Message Submission Agent (MSA) – агент подачи сообщений

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

Message Transfer Agent (MTA) – агент пересылки сообщений

Процесс, который соответствует спецификации [SMTP-MTA], действует как сервер SMTP для приема сообщений от MSA или других MTA и доставляет сообщения или выступает в качестве клиента SMTP для трансляции сообщений через другой MTA.

Message User Agent (MUA) – пользовательский почтовый агент

Процесс, который служит (обычно от имени пользователя) для создания и подачи новых сообщений, а также для обработки доставленных сообщений В модели “расщепленного агента6” для доступа к доставленной почте используется протокол POP или IMAP.

2.2. Используемые в документе соглашения

В примерах строки «C:» и «S:» показывают строки, передаваемые клиентом и сервером, соответственно. Перевод строки в командах дается лишь для удобства.

В примерах используется домен example.net.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), следует (SHOULD), не следует (SHOULD NOT), возможно (MAY) в данном документе должны интерпретироваться в соответствии с документом «Ключевые слова для обозначения уровня требований в RFC» [KEYWORDS].

3. Подача сообщений

3.1. Идентификация подачи сообщения

Данный документ резервирует порт с номером 587 для подачи сообщений. Сообщения, полученные через этот порт, предназначены для подачи серверу. В качестве протокола используется ESMTP [SMTP-MTA, ESMTP], с описанными здесь расширениями.

Большинство почтовых клиентов и серверов настраивается на использование порта 587 взамен порта 25, но в отдельных случаях это невозможно или неудобно. Сайт может выбрать использование для подачи сообщений порта 25, обозначив, что одни хосты являются агентами MSA, а другие – агентами MTA.

3.2. Отказ от приема сообщений

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

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

Примечание: Лучше отвергнуть сообщение, чем передавать сообщения с риском их повреждения. Это особенно важно для проблем, которые исправляются на уровне MUA (например, некорректное поле ‘From’).

Если MSA не может определить путь возврата для подающего сообщение пользователя из корректного значения MAIL FROM, корректного адреса IP или по результатам аутентификации, агенту MSA следует незамедлительно отвергнуть сообщение. Сообщение может быть незамедлительно отвергнуто путем возврата кода 550 команде MAIL FROM.

Отметим, что пустой путь возврата (т. е., MAIL FROM:<>) разрешен и должен приниматься (агентам MUA требуется генерация сообщений с пустым путем возврата по целому ряду причин, включая уведомления об уничтожении сообщений).

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

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

3.3. Уполномоченная подача сообщений

Множество методов используется для того, чтобы только уполномоченные пользователи могли передавать сообщения по электронной почте. К этим методам относятся аутентификация SMTP, ограничения по адресам IP, secure IP и предварительная POP-аутентификация.

Предлагается использовать расширение Authenticated SMTP [SMTP-AUTH]. Это расширение позволяет агенту MSA проверить полномочия пользователя при подаче сообщений, чего невозможно добиться при использовании других протоколов.

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

Можно также использовать Secure IP [IPSEC] – это решение обеспечивает дополнительную защиту от перехвата и анализа трафика.

Требование предварительной аутентификации POP [POP3] (с того же адреса IP) с некоторым (например, 20 минут) упреждением по отношению к подаче сообщений также может использоваться, но этот метод может вносить некоторые ограничения на использование клиентов и серверов. В частности, клиент должен выполнить процедуры POP-аутентификации до начала сеанса SMTP (подача сообщения), а это обеспечивают не все клиенты. Кроме того требуется координация MSA с POP-сервером, что может оказаться сложной задачей. Существует также интервал времени, в течение которого не имеющий полномочий пользователь может подать свое сообщение, просто опередив уполномоченного пользователя.

3.4. Расширенные коды состояния

В этом документе предлагается несколько дополнительных кодов состояния [SMTP-CODES] для связанных с подачей сообщений отказов. К таким кодам относятся:

5.6.0 Bad content – недопустимое содержимое заголовка или текста сообщения.

5.6.2 Bad domain or address – некорректный или недопустимый домен или адрес в команде MAIL FROM, RCPT TO или DATA.

5.7.1 Not allowed – Указанный в команде MAIL FROM адрес представляется некорректным, не имеет достаточных прав или используемый метод аутентификации не подтвердил полномочий для пользователя с этим адресом; адрес в команде RCPT TO несовместим с предоставленными пользователю полномочиями или данные сообщения отвергнуты с учетом подавшего сообщение пользователя.

5.7.0 Site policy – сообщение представляется противоречащим тем или иным правилам сайта.

4. Обязательные действия

Агент MSA должен выполнять все перечисленные в этой главе операции.

4.1. Код общего назначения для отказа при подаче сообщения

Если явно не указан специальный код, следует использовать код 554 для отказа от выполнения команд MAIL FROM, RCPT TO или DATA, содержащих что-либо некорректное. Если не задано иного, используется расширенный код 5.6.0.

4.2. Все домены должны быть полными (Fully-Qualified)

Агент MSA должен обеспечить полноту указания всех доменов в “конверте” сообщения (envelope).

Если MSA проверяет или изменяет текст сообщения, во всех случаях, за исключением добавления трассировочных заголовков [SMTP-MTA], агент должен должен обеспечить полноту указание доменов в адресных полях заголовка.

Код 554 используется для отказа от выполнения команд MAIL FROM, RCPT TO или DATA, содержащих некорректно указанные домены.

Примечание: Зачастую локальные соглашения допускают использование одноуровневых (single-level) доменов (например, ‘sales’) и тогда адрес расширяется добавлением оставшейся части доменного имени (например, до ‘sales.example.net’). Локальным соглашениям, которые допускают одноуровневые домены, следует отвергать, а не дополнять неполные многоуровневые доменные имена, поскольку дополнение таких имен связано с риском ошибки.

5. Рекомендуемые действия

Агенту MSA следует выполнять перечисленные в этой главе операции.

5.1. Обеспечение корректного синтаксиса адресов

Агенту MSA следует отвергать сообщения с некорректным синтаксисом адреса отправителя или получателя в “конверте” сообщения.

Если MSA проверяет или изменяет проверяет или изменяет текст сообщения, во всех случаях, за исключением добавления трассировочных заголовков [SMTP-MTA], агенту следует отвергать сообщения с некорректным синтаксисом адресов в адресных полях заголовка.

Код 501 используется для отказа от выполнения команд MAIL FROM и RCPT TO, содержащих недопустимые адреса.

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

5.2. Протоколирование ошибок

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

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

6. Дополнительные действия

Агент MSA может выполнять перечисленные в этой главе операции.

6.1. Выполнение правил подачи сообщений

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

Для этих целей используется код 550 с расширенным кодом состояния 5.7.1.

6.2. Требование аутентификации

MSA может возвращать код ошибки в ответ на команду MAIL FROM, если сессия не была аутентифицирована.

Механизм аутентификации рассматривается в параграфе 3.3.

Для этих целей используется код 530 [SMTP-AUTH].

6.3. Проверка полномочий

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

Для этих целей используется код 550 с расширенным кодом состояния 5.7.1.

6.4. Проверка данных в сообщении

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

Код 554 используется при обнаружении синтаксических проблем в данных. Код 501 служит для индикации синтаксической некорректности самой команды. Код 550 с расширенным кодом состояния 5.7.1 используется в случаях отказа для подавшего сообщение пользователя (нет прав). Код 550 с расширенным кодом состояния 5.7.0 указывает на несоответствие политике сайта.

7. Взаимодействие с расширениями SMTP

В приведенной ниже таблице указаны расширения предложенные в качестве стандартов и экспериментальные расширения SMTP. Таблица содержит номера RFC, имена расширений, информацию об использовании расширения на порту submit и ссылку на документ:

RFC Имя Использование с портом Submission Ссылка

2197

Pipelining

Нужно

[PIPELINING]

2034

Error Codes – коды ошибок

Нужно

[CODES-EXTENSION]

1985

ETRN

Недопустимо

[ETRN]

1893

Extended Codes – расширенные коды

Нужно

[SMTP-CODES]

1891

DSN

Нужно

[DSN]

1870

Size

Возможно

[SIZE]

1846

521

Недопустимо

[521REPLY]

1845

Checkpoint

Возможно

[Checkpoint]

1830

Binary

Возможно

[CHUNKING]

1652

8-bit MIME

Нужно

[8BITMIME]

—-

Authentication — аутентификация

——

[SMTP-AUTH]

Будущим расширениям SMTP следует явно указывать свою корректность по отношению к порту Submission.

Некоторые расширения SMTP особенно полезны для подачи сообщений:

Расширенные коды состояния7 [SMTP-CODES] следует поддерживать и использовать в соответствии с документом [CODES-EXTENSION]. Это позволяет агенту MSA уведомлять клиента о проблемах в его конфигурации или иных проблемах с предоставлением более подробной информации, нежели могут коды откликов, перечисленные в этом документе. Поскольку некоторые отказы могут быть связаны с политикой сайта, следует принять меры по предотвращению раскрытия информации, которое могло бы позволить обход ограничений политики.

[PIPELINING] следует поддерживать в MSA.

[SMTP-AUTH] позволяет MSA проверить полномочия и идентифицировать подавшего сообщение пользователя.

Все упоминания команды DATA в этом документе относятся также и к любым заменам этой команды, таким как команда BDAT, используемая в [CHUNKING].

8. Изменение сообщений

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

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

8.1. Добавление поля ‘Sender’

Агент MSA может добавлять или изменять поле ‘Sender’, если отправитель известен и не совпадает с указанным в поле ‘From’.

MSA должен обеспечить корректность почтового адреса, помещаемого в поле ‘Sender’.

8.2. Добавление поля ‘Date’

Агент MSA может добавлять поле ‘Date’ к поданному сообщению, если это поле отсутствует, или исправлять значение поля ‘Date’, если оно не соответствует синтаксису [MESSAGE-FORMAT].

8.3. Добавление поля ‘Message-ID’

Агент MSA может добавлять или изменять поле ‘Message-ID’ при его отсутствии или наличии синтаксических ошибок (см. [MESSAGE-FORMAT]).

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

Агент MSA может применять операции транспортного кодирования (transfer encoding) к сообщению в соответствии с соглашениями MIME при необходимости, если это не представляет опасности для данного типа MIME.

8.5. Включение сигнатуры

Агент MSA может создавать (цифровую) подпись для сообщения или добавлять к нему аутентификационные данные.

8.6. Шифрование сообщений

Агент MSA может шифровать сообщения для передачи в соответствии с политикой организации.

Примечание: При добавлении сигнатуры и/или шифровании сообщений на уровне агента MSA в общем случае предполагается, что для соединения между MUA и MSA тем или иным способом обеспечивается защита (например, использование в защищенной среде, защиты связанных с подачей соединений на транспортном уровне или использование механизма [SMTP-AUTH], обеспечивающего целостность сессий).

8.7. Преобразование псевдонимов

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

Примечание: Безусловное преобразование псевдонимов может представлять опасность. Например, если www.example.net и ftp.example.net являются псевдонимами mail.example.net после преобразования может теряться полезная информация.

8.8. Перезапись заголовков

Агент MSA может переписывать локальную часть адреса и/или доменное имя в конверте и (опционально) в адресных полях заголовка в соответствии с локальной политикой. Например, сайт может заменить ‘JRU’ на ‘ J.Random.User’ для того, чтобы скрыть регистрационное имя, или заменить ‘squeeky.sales.example.net’ на ‘zyx.example.net’ для сокрытия имени машины и упрощения процедур при перемещении пользователей.

Однако изменять следует только локальные части или доменные имена, которые соответствуют локальным конфигурационным параметрам MSA. Очень опасно применять для MSA независимые от данных правила замены (такие, как удаление первого элемента доменного имени). Например, правило, удаляющее первый (слева) элемент доменного имени, если это имя соответствует шаблону ‘*.foo.example.net’, является вполне приемлемым.

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

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

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

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

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

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

Этот обновленный вариант документа был частично пересмотрен с учетом комментариев и дискуссий в почтовой конференции IETF-Submit. Спасибо всем, кто потратил свое время на просмотр черновых вариантов и предложения, — особенно Dave Crocker, Ned Freed, Keith Moore, John Myers и Chris Newman.

Особой благодарности заслуживает Harald Alvestrand, давший начало этому документу.

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

[521REPLY] Durand, A. and F. Dupont, «SMTP 521 Reply Code», RFC 1846, September 1995.

[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E. And D. Crocker, «SMTP Service Extension for 8bit-MIMEtransport», RFC 1652, July 1994.

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

[CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, «SMTP Service Extension for Checkpoint/Restart», RFC 1845, September 1995.

[CHUNKING] Vaudreuil, G., «SMTP Service Extensions for Transmission of Large and Binary MIME Messages», RFC 1830, August 1995.

[CODES-EXTENSION] Freed, N., «SMTP Service Extension for Returning Enhanced Error Codes», RFC 2034, October 1996.

[DSN] Moore, K., «SMTP Service Extension for Delivery Status Notifications», RFC 1891, January 1996.

[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. And D. Crocker, «SMTP Service Extensions», STD 10, RFC 1869, November 1995.

[ETRN] De Winter, J., «SMTP Service Extension for Remote Message Queue Starting», RFC 1985, August 1996.

[HEADERS] Palme, J., «Common Internet Message Headers», RFC 2076, February 1997.

[IPSEC] Atkinson, R., «Security Architecture for the Internet Protocol», RFC 1825, August 1995.

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

[MESSAGE-FORMAT] Crocker, D., «Standard for the format of ARPA Internet text messages», STD 11, RFC 822, August 1982;

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

[PIPELINING] Freed, N., «SMTP Service Extension for Command Pipelining», RFC 2197, September 1997.

[POP3] Myers, J. and M. Rose, «Post Office Protocol — Version 3», STD 53, RFC 1939, May 1996.

[SIZE] Klensin, J., Freed, N. and K. Moore, «SMTP Service Extension for Message Size Declaration», STD 10, RFC 1870, November 1995.

[SMTP-AUTH] Myers, J., «SMTP Service Extension for Authentication», Work in Progress10.

[SMTP-CODES] Vaudreuil, G., «Enhanced Mail System Status Codes», RFC 1893, January 1996.

[SMTP-MTA] Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 82111, August 1982.

Partridge, C., «Mail Routing and the Domain System», STD 14, RFC 974, January 1986.

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

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

Randall Gellens

QUALCOMM Incorporated

6455 Lusk Blvd.

San Diego, CA 92121-2779

U.S.A.

Phone: +1 619 651 5115

Fax: +1 619 651 5334

EMail: Randy@Qualcomm.Com

John C. Klensin

MCI Telecommunications

800 Boylston St, 7th floor

Boston, MA 02199

USA

Phone: +1 617 960 1011

EMail: klensin@mci.net


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

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

nmalykh@gmail.com

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

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

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

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

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

1Message Transfer Agent.

2Message *submission* protocol.

3Message user agent.

4Message Submission Agent.

5Domain Name Service – служба доменных имен. Прим. перев.

6Split-MUA model.

7Extended Status Code.

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

9Перевод этого документа имеется на сайте http://www.protocols.ru. Прим. перев.

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

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




RFC 2460 Internet Protocol, Version 6 (IPv6) Specification

Network Working Group                                     S. Deering
Request for Comments: 2460                                     Cisco
Obsoletes: 1883                                            R. Hinden
Category: Standards Track                                      Nokia
                                                       December 1998

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

Internet Protocol, Version 6 (IPv6)

Specification

PDF

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

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

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

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

Тезисы

В этом документе приведена спецификация протокола Internet (IP1) версии 6 (Ipv6), который иногда называют также IP Next Generation2 или IPng.

Оглавление

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

1. Введение

IPv6 представляет собой новую версию протокола IP, предлагаемую в качестве замены протокола IP версии 4 (IPv4) [RFC-791]. Основные отличия между IPv4 и IPv6 можно отнести к нескольким категориям:

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

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

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

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

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

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

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

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

  • Аутентификация и приватность

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

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

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

node — узел

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

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

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

host — хост

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

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

Протокольный уровень, расположенный непосредственно над IPv6. Примерами такого уровня являются транспортные протоколы типа TCP и UDP, протоколы управления типа ICMP, протоколы маршрутизации типа OSPF, а также протоколы, «туннелируемые» через IPv6 (т. е., инкапсулированные в пакеты IPv6) типа IPX, 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) учитываются, как данные (т. е., размер таких заголовков включается в значение размера данных пакета).

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

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

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

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

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

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

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

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

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

В IPv6 необязательная информация сетевого уровня представляется в виде отдельных заголовков, которые могут размещаться в пакете между заголовком IPv6 и заголовком вышележащего уровня. Определено несколько таких заголовков, идентифицируемых значением поля 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        |
   +---------------+-----------------+------------------+-----------------

Заголовки расширения (за единственным исключением) не проверяются и не обрабатываются узлами на пути пересылки, пока пакет не достигнет узла (или множесства узлов при групповой адресации), указанного полем Destination Address в заголовке IPv6. На узле получателя при обычном демультиплексировании поля Next Header в заголовке IPv6 вызывается модуль для обработки первого заголовка расширения или заголовка вышележащего уровня, если заголовка расширения нет. Содержимое и семантика каждого заголовка расширения определяет потребность в обработке следующего заголовка. Следовательно, заголовки расширения должны обрабатываться строго в порядке их следования в пакете. Для получателя недопустимо сканирование пакета с целью поиска того или иного типа заголовка расширение для его обработки ранее, чем будут обработаны предшествующие заголовки расширения.

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

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

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

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

Hop-by-Hop Options;

Routing (Type 0);

Fragment;

Destination Options;

Authentication;

Encapsulating Security Payload.

Первые 4 типа заголовков описаны в этом документе, а два оставшихся в [RFC-2402] и [RFC-2406], соответственно.

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

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

заголовок IPv6;

заголовок Hop-by-Hop Options;

заголовок Destination Options6;

заголовок Routing;

заголовок Fragment;

заголовок Authentication7;

заголовок Encapsulating Security Payload3;

заголовок Destination Options8;

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

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

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

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

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

4.2 Опции

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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |  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) по адресу отправителя (Source Address).

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

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

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

Три описанных выше старших бита считаются частью поля Option Type, но не являются независимыми от типа опции (т. е. конкретная опция идентифицируется всеми 8 битами поля 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Options — опции

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

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

4.4 Заголовок Routing

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                       type-specific data                      .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Заголовок Routing используется источником пакетов IPv6 для указания одного или множества промежуточных узлов, которые пакет должен «посетить» на пути к адресату. Функционально этот заголовок очень похож на опции Loose Source и Record Route в заголовках IPv4. Заголовок Routing идентифицируется значением Next Header = 43 в предшествующем ему заголовке и использует показанный на рисунке формат.

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

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

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

8-битовое целое число без знака, указывающее размер заголовка Routing в 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) по адресу Source Address.

Если после обработки заголовка Routing получивший пакет узел определяет, что пакет будет пересылаться в канал, для которого значение MTU меньше размера пакета, этот узел должен отбросить пакет и передать сообщение ICMP Packet Too Big по адресу Source Address.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  | Routing Type=0| Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Reserved                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                           Address[1]                          +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                           Address[2]                          +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                               .                               .
.                               .                               .
.                               .                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                           Address[n]                          +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Заголовок Routing типа 011 имеет формат, показанный на рисунке.

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

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

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

8-битовое целое число без знака, указывающее размер заголовка Routing в 8-октетных словах без учета первых 8 октетов. Для заголовка Routing типа 0 значение поля Hdr Ext Len равно удвоенному числу адресов в этом заголовке.

Routing Type 0

Segments Left — число оставшихся сегментов

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

Reserved — резерв

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

Address[1..n] — адреса

Вектор из 128-битовых адресов с номерами от 1 до n.

Групповые адреса не должны появляться в заголовках Routing типа Type 0 или в поле IPv6 Destination Address пакетов, содержащих заголовок Routing типа 0.

Заголовок Routing не проверяется и не обрабатывается, пока пакет не достигнет узла, указанного в поле Destination Address заголовка IPv6. На этом узле диспетчеризация поля Next Header предыдущего заголовка приводит к вызову модуля обработки заголовка Routing, который в случае Routing Type = 0, реализует приведенный ниже алгоритм.

  if Segments Left = 0 {
     обработать следующий заголовок, тип которого указан полем Next Header в 
     заголовке Routing
  }
  else if Hdr Ext Len имеет нечетное знаение {
        передать по адресу Source Address сообщение ICMP Parameter Problem с кодом 0, 
        указывающее на поле Hdr Ext Len и отбросить пакет
  }
  else {
     рассчитать значение n (число адресов в заголовке Routing) путем деления 
     значения поля Hdr Ext Len на 2;
     if Segments Left > n {
        передать по адресу Source Address сообщение ICMP Parameter Problem с кодом 0,
        указывающее на поле Segments Left и отбросить пакет
     }
     else {
        уменьшить значение Segments Left на 1;
        рассчитать значение i (индекс следующего адреса из вектора адресов) путем
        вычитания значения Segments Left из n;
        if Address [i] или the IPv6 Destination Address является групповым {
           отбросить пакет
        }
        else {
           поменять местами IPv6 Destination Address и Address[i];
           if IPv6 Hop Limit  1 {
              передать сообщение ICMP Time Exceeded (Hop Limit Exceeded in  Transit)
              по адресу Source Address и отбросить пакет
           }
           else {
              уменьшить значение Hop Limit на 1;
              снова передать пакет модулю IPv6 для его отправки новому получателю
           }
        }
     }
  }

В качестве примера действия приведенного выше алгоритма рассмотрим случай, когда узел S передает пакеты получателю D, используя заголовок Routing для маршрутизации пакетов через промежуточные узлы I1, I2 и I3. Значения соответствующих полей заголовков IPv6 и Routing на каждом сегменте пути доставки показаны ниже.

Сегмент пути от S до I1:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I1            Segments Left = 3
                                            Address[1] = I2
                                            Address[2] = I3
                                            Address[3] = D

Сегмент пути от I1 до I2:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I2            Segments Left = 2
                                            Address[1] = I1
                                            Address[2] = I3
                                            Address[3] = D

Сегмент пути от I2 до I3:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I3            Segments Left = 1
                                            Address[1] = I1
                                            Address[2] = I2
                                            Address[3] = D

Сегмент пути от I3 до D:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = D             Segments Left = 0
                                            Address[1] = I1
                                            Address[2] = I2
                                            Address[3] = I3

4.5 Заголовок Fragment

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Заголовок Fragment используется отправителем IPv6 для передачи пакетов, размер которых превышает значение path MTU для получателя12. Заголовок Fragment идентифицируется значением Next Header = 44 в непосредственно предшествующем заголовке и имеет формат, показанный на рисунке.

Next Header — тип фрагментируемой части

8-битовый селектор, определяющий исходный тип заголовка фрагментируемой части (Fragmentable Part) исходного пакета (см. определение ниже). Используются те же значения, которые применяются в поле Protocol заголовков IPv4 [RFC-1700 и его преемники].

Reserved — резерв

8-битовое резервное поле. При передаче это поле заполняется нулями, а на приемной стороне игнорируется.

Fragment Offset — смещение фрагмента

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

Res

2-битовое резервное поле. При передаче это поле заполняется нулями, а на приемной стороне игнорируется.

Флаг M

1 — есть еще фрагменты; 0 — последний фрагмент.

Identification — идентификация

32 бита (см. описание ниже).

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

Для каждого пакета, который будет фрагментироваться, узел-источник генерирует значение Identification. Это значение для фрагментированного пакета должно отличаться от значений для фрагментированных пакетов, переданных «недавно»13 с такими же значениями полей Source Address и Destination Address. При наличии заголовка Routing для фрагментированных пакетов Destination Address трактуется, как адрес конечного получателя.

+-------------------+----------------------//-----------------------+
| Нефрагментируемая |               Фрагментируемая                 |
|       часть       |                     часть                     |
+-------------------+----------------------//-----------------------+

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

Нефрагментируемая часть (Unfragmentable Part) состоит из заголовка IPv6 и всех заголовков расширения, которые должны обрабатываться узлами на пути к получателю (т. е., все заголовки расширения до Routing, включительно, если он имеется, или Hop-by-Hop Options, включительно, если он имеется).

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

Фрагментируемая часть исходного пакета делится на фрагменты, размер каждого из которых (за исключением последнего) кратен 8 октетам. Фрагменты передаются в отдельных «фрагментированных пакетах», как показано на рисунке.

Исходный пакет

   +------------------+--------------+--------------+--//--+----------+
   | Нефрагментируемая|    первый    |    второй    |      |последний |
   |      часть       |   фрагмент   |   фрагмент   | .... | фрагмент |
   +------------------+--------------+--------------+--//--+----------+

Фрагментированные пакеты

   +------------------+---------+--------------+
   | Нефрагментируемая|заголовок|    первый    |
   |      часть       |фрагмента|   фрагмент   |
   +------------------+---------+--------------+

   +------------------+---------+--------------+
   | Нефрагментируемая|заголовок|    второй    |
   |      часть       |фрагмента|   фрагмент   |
   +------------------+---------+--------------+
                         o
                         o
                         o
   +------------------+---------+----------+
   | Нефрагментируемая|заголовок|последний |
   |      часть       |фрагмента| фрагмент |
   +------------------+---------+----------+

Каждый пакет с фрагментом состоит из нескольких компонент.

  1. Нефрагментируемая часть исходного пакета со значением поля Payload Length в исходном заголовке IPv6 в соответствии с реальным размером фрагментированного пакета (без учета самого заголовка IPv6) и значением поля Next Header в последнем заголовке нефрагментируемой части, равным 44.

  2. Заголовок фрагмента, включающий:

    Значение Next Header, идентифицирующее первый заголовок фрагментируемой части исходного пакета.

    Поле Fragment Offset указывающее смещение фрагмента (в 8-октетных словах) от начала фрагментируемой части исходного пакета. Для первого (самого левого) фрагмента Fragment Offset = 0.

    Флаг M имеет значение 0 для последнего фрагмента и 1 для всех прочих фрагментов.

    Значение Identification, созданное для исходного пакета.

  3. Собственно фрагмент.

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

+-------------------+----------------------//-----------------------+
| Нефрагментируемая |               Фрагментируемая                 |
|       часть       |                     часть                     |
+-------------------+----------------------//-----------------------+

На приемной стороне фрагменты пакета собираются заново в исходный нефрагментированный пакет, как показано на рисунке.

Сборка фрагментов выполняется в соответствии с приведенными ниже правилами.

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

Нефрагментируемая часть собираемого из фрагментов пакета содержит все заголовки, вплоть до заголовка Fragment (но не включая его) первого пакета с фрагментом (т. е., Fragment Offset = 0) с двумя изменениями:

Значение поля Next Header в последнем заголовке нефрагментируемой части берется из одноименного поля в заголовке Fragment первого фрагмента.

Значение поля Payload Length собираемого пакета вычисляется на основе размера нефрагментируемой части, а также размера и смещения последнего фрагмента. Например, значение этого поля для собранного исходного пакета можно вычислить по формуле:

           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 в последнем 
                      пакете с фрагментом.

Фрагментируемая часть исходного пакета восстанавливается из фрагментов, следующих после заголовков Fragment в каждом из пакетов с фрагментами. Размер каждого фрагмента определяется путем вычитания из значения поля Payload Length размера заголовков между заголовком IPv6 и самим фрагментом; положение фрагмента в Fragmentable Part определяется по значению поля Fragment Offset.

Заголовок Fragment не присутствует в собранном заново исходном пакете.

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

Если в течение 60 секунд с момента приема первого фрагмента получены не все фрагменты, требуемые для сборки, сборка должна быть прервана, а все полученные фрагменты — отброшены. Если первый фрагмент (т. е. пакет со значением Fragment Offset = 0) был получен, отправителю этого фрагмента следует передать сообщение ICMP Time Exceeded (Fragment Reassembly Time Exceeded14).

Если размер фрагмента, определенный из значения поля Payload Length в заголовке пакета с фрагментом, не кратен 8 октетам, а флаг M имеет значение 1, этот фрагмент должен отбрасываться, а отправителю фрагмента следует передать сообщение ICMP Parameter Problem с кодом 0, указывающее на поле Payload Length пакета с фрагментом.

Если значения размера и смещения для фрагмента таковы, что значение поля Payload Length собранного из фрагментов пакета будет превышать 65 535 октетов, этот фрагмент должен быть отброшен, а его отправителю следует передать сообщение ICMP Parameter Problem с кодом 0, указывающее на поле Fragment Offset в пакете с фрагментом.

Перечисленные ниже ситуации являются нежелательными, но не трактуются, как ошибки.

Число и содержимое заголовков, предшествующих заголовку Fragment в разных фрагментах одного исходного пакета могут различаться. Независимо от того, какие заголовки присутствуют в каждом фрагменте перед заголовком Fragment, они обрабатываются до того, как фрагменты будут помещены в очередь на сборку. В собранном пакете остаются лишь заголовки из фрагментированного пакета с Offset = 0.

Значения Next Header в заголовках Fragment различных фрагментов одного исходного пакета могут различаться. Для сборки фрагментов используется только значение из пакета, содержащего фрагмент с нулевым смещением.

4.6 Заголовок Destination Options

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

Заголовок Destination Options используется для передачи дополнительной информации, которая будет просматриваться только на конечном узле(ах). Заголовок Destination Options идентифицируется значением Next Header = 60 в предшествующем непосредственно заголовке и имеет формат, показанный на рисунке.

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

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

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

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

8-битовое целое число без знака, указывающее размер заголовка Destination Options в 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, эти октеты должны игнорироваться и пересылаться без изменений.

5. Размер пакетов

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

Каналы с настраиваемым значением MTU (например, PPP [RFC-1661]) должны настраиваться на использование значений MTU не менее 1280 октетов. Рекомендуется устанавливать значение MTU не менее 1500 октетов для обеспечения возможности инкапсуляции (например, туннелирования) без фрагментации на уровне IPv6.

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

Для узлов IPv6 настоятельно рекомендуется поддержка механизма Path MTU Discovery [RFC-1981] для обнаружения и использования преимуществ MTU > 1280 октетов. Однако минимальные реализации IPv6 (например, в загрузочных ПЗУ) могут ограничиваться передачей пакетов, размер которых не превышает 1280 октетов и не поддерживать Path MTU Discovery.

Для передачи пакетов, размер которых превышает path MTU, узел может использовать заголовок IPv6 Fragment для фрагментации пакета на стороне отправителя и сборки фрагментов на стороне получателя(ей). Однако такой фрагментации следует избегать во всех приложениях, которые могут подстраивать размер пакетов под измеренное значение path MTU (например, до 1280 октетов).

Узел должен быть способен воспринимать фрагментированные пакеты, размер которых после сборки достигает 1500 октетов, и может воспринимать пакеты, размер которых после сборки фрагментов превышает 1500 октетов. Протоколам или приложениям вышележащего уровня, зависящим от фрагментации IPv6, для передачи пакетов с размером больше MTU для пути не следует передавать пакетов размером более 1500 октетов, если нет уверенности в том, что получатель может собирать из фрагментов пакеты размером более 1500 октетов .

В ответ на пакет IPv6, отправленный адресату IPv4 (т. е., пакет, преобразованный из IPv6 в IPv4), узел-источник IPv6 может получить сообщение ICMP Packet Too Big, указывающее, что Next-Hop MTU < 1280. В таких случаях от узла IPv6 не требуется снижать размер пакетов до значения меньше 1280. Узел в таких случаях должен использовать заголовок Fragment в пакетах так, чтобы маршрутизатор, выпроняющий преобразование IPv6 в IPv4 получил подходящее значение Identification для использования в последующих фрагментах IPv4. Отметим, что это может потребовать снижения размера данных в пакете до 1232 октетов (1280 — 40 октетов заголовка IPv6 и 8 октетов заголовка Fragment) или меньше, если используются и другие заголовки расширения15.

6. Метки потоков

20-битовое поле Flow Label в заголовке IPv6 может быть использовано отправителем для маркировки последовательности пакетов, требующей специальной обработки в маршрутизаторах IPv6 (например, отличное от принятого по умолчанию качество сервиса или обслуживание пакетов в реальном масштабе времени). Во время подготовки этого документа этот аспект IPv6 оставался экспериментальным и был связан с изменением требований к поддержке потоков в сети Internet. Хосты и маршрутизаторы, не поддерживающие использование поля Flow Label, должны устанавливать для него нулевое значение в создаваемых пакетах, оставлять значение поля неизменным при пересылке пакетов и игнорировать поле в принимаемых пакетах.

Предполагаемая семантика и применение поля Flow Label описаны в Приложении A.

В отличие от RFC 1883 данная спецификация уменьшает размер метки потока до 20 битов. Упоминание 24-битовых меток на страницах 87 и 88 документа RFC 2205 следует обновить соответственно16.

7. Классы трафика

8-битовое поле Traffic Class в заголовке IPv6 может использоваться отправителями и/или пересылающими пакеты маршрутизаторами для идентификации и разделения различных классов или приоритетов для пакетов IPv6. К моменту написания этого документа было выполнено множество экспериментов по использованию флагов Type of Service и/или Precedence протокола IPv4 для реализации различных форм дифференцированного обслуживания пакетов IP, отличающихся от явной организации потоков. Поле Traffic Class в заголовке IPv6 предназначено для поддержки аналогичных функций в IPv6.

Есть надежда, что эксперименты позволят достичь согласия по вопросу выбора методов классификации трафика, которые будут наиболее полезны для пакетов IP. Детальное описание синтаксиса и семантики всех или некоторых битов поля IPv6 Traffic Class (экспериментальных или планируемых для стандартизации) приведены в отдельных документах.

Ниже приведены общие требования, применимые к полю Traffic Class.

  • Интерфейс к услугам IPv6 на узле должен обеспечивать протоколам вышележащего уровня механизм передачи битов Traffic Class в пакетах, порождаемых протоколом вышележащего уровня. По умолчанию все 8 битов поля должны иметь нулевые значения.

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

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

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

8.1 Контрольные суммы вышележащего уровня

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Upper-Layer Packet Length                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      zero                     |  Next Header  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Любой транспортный протокол или иной протокол вышележащего уровня, который включает адреса из заголовка IP в расчет контрольной суммы, должен быть изменен для использования с протоколом IPv6, в котором применяются 128-битовые адреса IPv6 взамен 32-битовых адресов IPv4. Приведенный рисунок показывает «псевдозаголовок» TCP и UDP для IPv6.

  • Если пакет 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 с нулевым значением контрольной суммы и записывать этот факт в системный журнал.

Протокол ICMP для IPv6 [ICMPv6] включает описанный выше псевдозаголовок в расчет контрольной суммы (в отличие от протокола ICMP для IPv4, где псевдозаголовок не учитывается в контрольной сумме). Это сделано для защиты ICMP от ошибочной доставки или повреждения тех полей в заголовках IPv6, от которых зависит ICMP и которые, в отличие от IPv4, не учитывается в контрольной сумме сетевого уровня. Поле Next Header в псевдозаголовке для ICMP содержит значение 58, идентифицирующее версию IPv6 протокола ICMP.

8.2 Максимальное время жизни пакета

В отличие от IPv4, узлы IPv6 не обязаны соблюдать максимальное время жизни пакетов. По этой причине поле «Time to Live» (TTL) протокола IPv4 переименовано в «максимальное число интервалов» (Hop Limit) в IPv6. На практике очень немногие реализации IPv4 соответствуют требованиям по ограничению времени жизни пакетов, поэтому внесенное в протокол изменение не имеет существенного практического значения. Любой протокол вышележащего уровня, который опирается на сетевой уровень (неважно, IPv4 или IPv6) для ограничения времени жизни пакетов, должен быть обновлен для обеспечения собственных механизмов детектирования и отбрасывания устаревших пакетов.

8.3 Максимальный размер данных вышележащего уровня

При расчете максимального размера данных, доступного протоколу вышележащего уровня, этот протокол должен принимать во внимание больший размер заголовков IPv6 по сравнению с IPv4. Например, в IPv4 опция TCP MSS17 рассчитывается, как максимальный размер пакета (принятое по умолчанию или полученное от механизма 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 в полученном пакете были проверены отвечающей стороной.

Приложение A. Семантика и применение поля Flow Label

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

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

Метка потока присваивается ему на узле — источнике потока. Новые метки потоков должны выбираться с использованием (псевдо)случайных значений, равномерно распределенных в диапазоне от 1 до FFFFF. Использование случайных значений выбрано для того чтобы любой набор битов поля метки Flow Label мог служить в качестве хэш-ключа для просмотра состояний, связанных с потоками, на маршрутизаторах.

Все пакеты, относящиеся к одному потоку, должны передаваться с одинаковыми значениями адресов отправителя и получателя, а также одинаковыми метками потока. Если любой из пакетов потока содержит заголовок Hop-by-Hop Options, все остальные пакеты этого потока должны генерироваться с такими же заголовками Hop-by-Hop Options (за исключением поля Next Header в заголовке Hop-by-Hop Options). Если любой из пакетов потока включает заголовок Routing, все остальные пакеты потока должны генерироваться с таким же содержимым заголовков расширения вплоть до заголовка Routing включительно (исключением является лишь поле Next Header в заголовке Routing). Маршрутизаторы и получатель могут, но не обязаны, проверять соблюдение приведенных выше условий. При обнаружении нарушения условий следует возвращать отправителю сообщение ICMP Parameter Problem с кодом 0, указывающее на старший октет поля Flow Label (т. е., смещение 1 в заголовке IPv6).

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

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

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

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

В этом приложении приведены некоторые рекомендации по расположению полей в новых опциях для использования с заголовками расширения 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-octet field                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 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-octet field |         2-octet field         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PadN Option=1 |Opt Data Len=4 |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |       0       | Option Type=X |Opt Data Len=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         4-октетное поле                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         8-октетное поле                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Вопросы безопасности IPv6 рассмотрены в документе «Архитектура безопасности для протокола Internet» [RFC-2401].

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

Адресы благодарят за множество полезных предложений членов рабочей группы IPng, исследовательской группы End-to-End Protocols, а также все сообщество Internet.

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

Stephen E. Deering

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA

Phone: +1 408 527 8213

Fax: +1 408 527 8254

EMail: deering@cisco.com

Robert M. Hinden

Nokia

232 Java Drive

Sunnyvale, CA 94089

USA

Phone: +1 408 990-2004

Fax: +1 408 743-5677

EMail: hinden@iprg.nokia.com

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

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

nmalykh@gmail.com

Литература

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

[RFC-2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 240219, November 1998.

[RFC-2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Protocol (ESP)», RFC 240620, November 1998.

[ICMPv6] Conta, A. and S. Deering, «ICMP for the Internet Protocol Version 6 (IPv6)», RFC 246321, December 1998.

[ADDRARCH] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 237322, July 1998.

[RFC-1981] McCann, J., Mogul, J. and S. Deering, «Path MTU Discovery for IP version 6», RFC 1981, August 1996.

[RFC-791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC-1700] Reynolds, J. and J. Postel, «Assigned Numbers», STD 2, RFC 170023, October 1994. См. также: http://www.iana.org/numbers.html

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

Отличия от RFC 1883

Этот документ имеет ряд отличий от RFC 1883. Эти различия перечислены ниже с указанием версии документов Internet-Draft, в которых изменения были внесены.

02) Удалены все упоминания джамбограмм (jumbogram) и опции Jumbo Payload (перенесено в отдельный документ).

02) Большая часть описания меток потока (Flow Label) перенесена из раздела 6 в (новое) Приложение A.

02) В описании Flow Label (сейчас Приложение A) максимальное значение поля Flow Label FFFFFF заменено на FFFFF (т. е., меньше на одну F) для уменьшения размера Flow Label с 24 до 20 битов.

02) Приложение A переименовано в Приложение B.

02) Заменен текст раздела «Вопросы безопасности» (Security Considerations) во избежание путаницы между этой спецификацией и спецификациями IPsec.

02) Обновлен адрес электронной почты и место работы R. Hinden.

———————————————————

01) В разделе 3 изменено название поля Class на Traffic Class, а размер этого поля увеличен с 4 до 8 битов. Уменьшен размер поля Flow Label с 24 до 20 битов для компенсации увеличения размера поля Traffic Class.

01) В параграфе 4.1 восстановлен порядок заголовков Authentication и ESP, который был по ошибке перепутан в черновом варианте 00.

01) В параграфе 4.1 удалено поле Strict/Loose Bit Map и функциональность строгого задания маршрута из заголовка Routing типа 0, а также удалено ограничение числа адресов, которые могут передаваться в заголовке Routing типа 0 (раньше число адресов не должно было превышать 23 в связи с размером битового отображения strict/loose).

01) В разделе 5 минимальное значение IPv6 MTU изменено с 576 на 1280 октетов и добавлена рекомендация для каналов с настраиваемым значением MTU (например, PPP) поддерживать значение MTU не менее 1500 октетов.

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

01) Ссылка на спецификацию механизма IPv4 Path MTU Discovery (RFC 1191) заменена ссылкой на спецификацию IPv6 Path MTU Discovery (RFC 1981) и удалены примечания в конце раздела 5, относящиеся к Path MTU Discovery, поскольку эти детали включены сейчас в RFC 1981.

01) В разделе 6 удалена спецификация «оппортунистической» организации потока, а также все ссылки на 6-секундное максимальное время жизни для таких «оппортуричстических» состояний.

01) В разделе 7 удалено описание внутренней структуры и сементики поля Traffic Class и указано, что эти описания представлены в отдельных документах.

———————————————————

00) В разделе 4 исправлено значение кода для индикации нераспознанного типа следующего заголовка (unrecognized Next Header type encountered) в сообщении ICMP Parameter Problem (код 2 заменен кодом 1).

00) В описании поля Payload Length в разделе 3 и поля Jumbo Payload Length в параграфе 4.3 даны разъяснения о том, что размер заголовков расширения учитывается в размере данных.

00) В параграфе 4.1 изменен порядок заголовков Authentication и ESP (это было ошибкой, которая была исправлена в версии 01).

00) В параграфе 4.2 даны разъяснения о том, что опции идентифицируются полным 8-битовым значением Option Type, а не только 5 битами поля Option Type. Также указано, что заголовки Hop-by-Hop Options и Destination Options используют общее пространство значений Option Type.

00) В параграфе 4.4 добавлено предложение, требующее от узлов при обработке заголовка Routing передавать сообщение ICMP Packet Too Big (например, вместо фрагментации) в ответ на получение пакета, размер которого слишком велик для канала на следующем интервале.

00) Имя поля IPv6 Priority заменено на Class и, соответственно, описание Priority в разделе 7 заменено описанием поля Class. Кроме того, это поле исключено из набора полей, которые должны совпадать во всех пакетах одного потока (раздел 6).

00) В псевдозаголовке (параграф 8.1) имя поля Payload Length заменено на Upper-Layer Packet Length. Разъяснено также, что для протоколов, поддерживающих свои данные о размере (например, UDP без jambo), в этом поле указывается размер от протокола вышележащего уровня (а не размер от IP).

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

00) Исправлены опечатки и грамматические ошибки.

00) Обновлены контактные данные авторов.

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

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

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

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

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

1Internet Protocol.

2Протокол IP следующего поколения.

3Область действия.

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

5Нераспознан тип следующего заголовка.

6Для опций, которые будут обрабатываться первым получателем, указанным в поле IPv6 Destination Address, плюс получатели, указанные далее в заголовке Routing.

7Дополнительные требования к относительному порядку заголовков Authentication и Encapsulating Security Payload приведены в [RFC-2406].

8Для опций, обрабатываемых только адресатом пакета.

9Type-length-value — тип-размер-значение.

10Формат опции Pad1 отличается от обычного TLV — опция не включает полей размера и значения.

11Использование заголовков Routing типа 0 запрещено RFC 5095. Причиной запрета является уязвимость, порождаемая этим типом заголовков. Прим. перев.

12В отличие от IPv4 фрагментация в IPv6 выполняется только узлами-отправителями, а не маршрутизаторами на пути доставки (см. раздел 5).

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

14Истекло время сборки фрагментов.

15В http://www.rfc-editor.org/errata_search.php?eid=2843 было предложено удалить этот абзац (предложение отвергнуто). Прим. перев.

16Этот абзац отсутствует в исходном документе. См. http://www.rfc-editor.org/errata_search.php?eid=2541. Прим. перев.

17Максимальный размер сегмента TCP.

18Этот документ признан устаревшим и заменен RFC 4301. Прим. перев.

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

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

21Этот документ признан устаревшим и заменен RFC 4443. Прим. перев.

22Этот документ признан устаревшим и заменен RFC 3513. Прим. перев.

23Этот документ был последним в серии «Assigned Numbers», отмененной RFC 3232. В настоящее время реестры выделенных значений доступны на сайте IANA. Прим. перев.

 




RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

Network Working Group                                     K. Nichols
Request for Comments: 2474                             Cisco Systems
Obsoletes: 1455, 1349                                       S. Blake
Category: Standards Track            Torrent Networking Technologies
                                                            F. Baker
                                                       Cisco Systems
                                                            D. Black
                                                     EMC Corporation
                                                       December 1998

Определение поля DS в заголовках IPv4 и IPv6

Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

PDF

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

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

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

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

Тезисы

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

  • установка битов в полях заголовка IP на границах сетей (границы автономных систем, внутренние административные границы, хосты);

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

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

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

В этом документе определено поле заголовка IP, которое называется DS1. Для IPv4 документ определяет схему октета TOS, для IPv6 — октета Traffic Class. В дополнение к этому определен базовый набор вариантов обработки пакетов при пересылке.

Более подробное описание дифференцированных услуг содержится в документе [ARCH], посвященном архитектуре Diffserv.

Оглавление

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

1. Введение

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

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

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

Конфигурация элементов сети, за счет использования которых пакетам обеспечивается специальная обработка, и правила, применимые к использованию ресурсов, изучены гораздо слабее. Тем не менее, возможно развертывание систем дифференцированного обслуживания в сетях на основе простых правил и статических конфигураций. Как указано в работе [ARCH], существует множество способов организации поведения на каждом этапе и кондиционирования трафика для дифференциации услуг. В процессе эксплуатации таких систем накапливается дополнительный опыт, позволяющий создавать более сложные правила и распределение ресурсов. Базовое поведение на пути пересылки при этом может сохраняться, но компоненты архитектуры будут развиваться. Опытное использование такого сервиса должен быть достаточно продолжительным и мы не предлагаем сразу стандартизовать решение — это было бы преждевременным. Более того, многие детали дифференциации услуг связаны с контрактными соглашениями между различными предприятиями и организациями, а этот вопрос выходит за пределы компетенции IETF.

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

Маркирование выполняется кондиционерами трафика на границах сетей, включая краевые узлы (первый маршрутизатор или хост-источник) и административные границы. Кондиционеры трафика могут включать примитивы маркировки, измерения, реализации политики и формовки (эти механизмы описаны в [ARCH]). Услуги реализуются путем использования классификации отдельных пакетов и механизмов кондиционирования трафика на границе, а также конкатенации поэтапного поведения на пути транзита трафика. Целью архитектуры дифференцированного обслуживания является определение «строительных блоков» с учетом расширения в будущем как числа, так и типов этих блоков, а также расширения спектра услуг, обеспечиваемых на их основе.

Используемая в документе терминология определена в разделе 2. Поле дифференцированного обслуживания (DS) рассматривается в разделе 3. Раздел 4 посвящен описанию частичной совместимости со сложившейся практикой использования поля Precedence в IPv4. В качестве решения предлагаются коды селекторов класса и совместимые с селектором класса PHB. В разделе 5 приводятся рекомендации по стандартизации поэтапного поведения. Раздел 6 содержит рекомендации по распределению кодов. В разделе 7 рассматриваются вопросы безопасности. Документ в целом представляет собой описание поля DS и его использования. Документ следует читать вместе с описанием архитектуры дифференцированного обслуживания [ARCH].

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

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

Behavior Aggregate — агрегат поведения

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

Classifier — классификатор

Объект, который выбирает пакет на основе содержимого заголовков в соответствии с заданными правилами.

Class Selector Codepoint — код селектора класса

Любой из восьми кодов xxx000 (x может принимать значение 0 или 1). Коды селекторов класса рассматриваются в параграфе 4.2.2.

Class Selector Compliant PHB — совместимое с селектором класса поэтапное поведение

Поэтапное поведение, удовлетворяющее требованиям к Class Selector PHB, приведенным в параграфе 4.2.2.2.

Codepoint — код

Конкретное значение компоненты DSCP поля DS. Рекомендованные коды следует отображать на конкретные, стандартизованные PHB. Множество кодов может отображаться на один PHB.

Differentiated Services Boundary — граница дифференцированных услуг

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

Differentiated Services-Compliant — совместимость с дифференцированным обслуживанием

Соответствие требованиям данного документа. Используется также термин «совместимость с DS».

Differentiated Services Domain — домен дифференцированных услуг

Непрерывное подмножество Internet, в котором обеспечивается согласованный набор правил дифференцированного обслуживания. Домен дифференцированных услуг может быть представлен разными административными доменами, автономными системами, областями доверия, сетевыми технологиями (например, коммутация кадров/ячеек), хостами, маршрутизаторами и т. п. Используется тайже термин DS-домен.

Differentiated Services Field — поле DS

Октет TOS в заголовке IPv4 или октет Traffic Class в заголовке IPv6, который интерпретируется в соответствии с определениями данного документа.

Mechanism — механизм

Реализация одного или множества вариантов поэтапного поведения в соответствии с определенным алгоритмом.

Microflow — микропоток

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

Per-hop Behavior (PHB) — поэтапное поведение

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

Per-hop Behavior Group — группа PHB

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

Traffic Conditioning — кондиционирование трафика

Функции управления, которые могут быть применены к агрегату поведения, потоку приложений или другому подмножеству трафика (например, маршрутным обновлениям). Кондиционирование может включать измерение, исполнение правил, формовку и маркировку пакетов. Кондиционирование трафика используется для реализации соглашения между доменами и приведения трафика в соответствие с политикой дифференцированного обслуживания в домене путем маркировки пакетов соответствующим кодом DS и мониторинга временных параметров агрегата с генерацией сигналов, когда это требуется. См. [ARCH].

Traffic Conditioner — кондиционер трафика

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

Service — сервис, услуга

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

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

Дополнительные определения дифференцированных услуг даны в документе [ARCH].

3. Определение поля DS

Здесь дано определение поля DS, которое предназначено для замены существующих определений октета TOS в заголовках IPv4 [RFC791] и октета Traffic Class в заголовках IPv6 [IPv6]4.

Шесть битов поля DS используются в качестве кода DSCP для выбора варианта PHB, с которым будет сталкиваться пакет на каждом узле. Двухбитовое поле CU является резервным, его определение и использование выходит за рамки данного документа. Значение битов CU игнорируется узлами, поддерживающими дифференцированное обслуживание, при определении поэтапного поведения для полученного пакета.

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|         DSCP          |  CU   |
+---+---+---+---+---+---+---+---+

Структура поля DS показана на рисунке.

DSCP5 — код дифференцированного обслуживания;

CU6 — не используется в настоящее время.

При указании значений DSCP используется нотация «xxxxxx» (x может принимать значения 0 и 1), где в крайней левой позиции указывается бит 0 поля DS (как показано на рисунке), а в крайней правой — бит 5.

Разработчикам следует отметить для себя, что размер поля DSCP составляет 6 битов. Поддерживающие DS узлы должны выбирать PHB, проверяя соответствие всему 6-битовому поля DSCP (например, трактуя значение поля, как индекс таблицы, используемой для выбора режима обслуживания пакетов, реализованного в данном устройстве). Значения поля CU должны игнорироваться при выборе PHB. Поле DSCP трактуется, как бесструктурное, чтобы обеспечить в будущем возможность определения разных вариантов поэтапного поведения.

С некоторыми исключениями, отмеченными ниже, отображение кодов на PHB должно быть настраиваемым. Соответствующие DS узлы должны поддерживать логический эквивалент настраиваемой таблицы отображения кодов в PHB. Спецификации PHB должны включать рекомендуемый по умолчанию код, который должен быть уникальным в стандартном пространстве кодов (см. раздел 6). Реализациям следует поддерживать рекомендуемые отображения кодов в PHB в принятой по умолчанию конфигурации. Операторы могут выбирать использование различных кодов для PHB в дополнение к рекомендуемым по умолчанию или вместо них. Отметим, что при таком выборе может потребоваться перемаркировка полей DS на административных границах даже в тех случаях, когда по обе стороны границы реализованы одинаковые PHB.

Вопросы перемаркировки более подробно рассмотрены в [ARCH].

Исключения из общих правил относятся к кодам xxx000 и рассмотрены в параграфах 4.2.2 и 4.3.

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

Показанная выше структура поля DS не совместима с существующим определением октета IPv4 TOS [RFC791]. Предполагается, что домены DS защищают себя, реализуя граничные узлы перемаркировки, как следует делать сетям, использующим поле RFC 791 Precedence. Процедуры перемаркировки следует выполнять в соответствии с [RFC791], где сказано: «Если та или иная сеть использует значение уровня предпочтения, она берет на себя ответственность за доступ к этому полю и его использование8». Проверка значения поля DS на границах DS осмысленна в любом случае, поскольку узел восходящего направления может легко установить для этого поля любое значение. Домены DS, не отделенные подобающим образом настроенными узлами, могут предлагать непредсказуемый сервис.

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

4. Требования к старым кодам и PHB

Как отмечено в этом разделе, поле DS обеспечивает лишь ограниченную совместимость с современной практикой. Вопрос совместимости с более ранними версиями решается двумя способами. Во-первых, существуют варианты поэтапного поведения, которые уже получили достаточно широкое распространение (например, варианты, удовлетворяющие требованиям к управлению очередями на основе поля IPv4 Precedence, заданным в [RFC1812]), и мы хотим сохранить возможность их использования на поддерживающих DS узлах. Кроме того, существуют некоторые коды, соответствующие сложившемуся использованию поля IP Precedence, и эти коды резервируются для отображения на PHB, которые соответствуют заданным в параграфе 4.2.2.2 общим требованиям, хотя конкретные PHB дифференцированного обслуживания, на которые отображаются эти коды, могут иметь дополнительные спецификации.

Здесь не предпринимается попыток обеспечить совместимость с DTR или битами TOS октета IPv4 TOS, определенного в [RFC791]10.

4.1 PHB по умолчанию

Используемый по умолчанию вариант PHB должен быть доступен на поддерживающих DS узлах. Это обычное поведение с обеспечением пересылки по возможности11, доступное в существующих маршрутизаторах и стандартизованное в [RFC1812]. При отсутствии других соглашений предполагается, что пакеты относятся к этому агрегату. Такие пакеты могут передаваться в сеть без выполнения каких-либо специальных правил и сеть будет доставлять эти пакеты в таком количестве и с таким качеством, как это возможно в соответствии с существующими правилами ограничения ресурсов. Подходящей реализацией такого PHB будет дисциплина очередей, обеспечивающая передачу пакетов этого агрегата, когда выходной канал не требуется для других PHB. Подходящим правилом для конструирования сервиса будет «поддержание жизни» для этого агрегата. Это может быть реализовано на каждом узле с помощью механизма, резервирующего некие минимальные ресурсы (например, буферы или полосу) для принятого по умолчанию агрегата поведения. Такой подход позволит отправителям, не поддерживающим дифференцированное обслуживание, использовать сети так же, как это происходило без дифференциации. Влияние введения дифференцированных услуг в домене на обслуживание пользователей и партнеров является достаточно сложным вопросом, включающим политику домена, и выходит за рамки данного документа. Рекомендуемым кодом для принятого по умолчанию PHB является 000000, значение кода 000000 должно отображаться на PHB, который соответствует данной спецификации. Выбранный для принятого по умолчанию поведения код совместим с существующей практикой [RFC791]. Если код не отображается на стандартизованный или локальный PHB, его следует отображать на принятый по умолчанию PHB.

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

4.2 Настоящее и будущее поля IP Precedence

Мы хотим создать некую форму совместимости с современным использованием поля IP Precedence — битами 0 — 2 октета IPv4 TOS. Существуют маршрутизаторы, использующие поле IP Precedence для выбора различных режимов поэтапной пересылки, подобно использованию предложенного здесь поля DSCP. Таким образом, простой прототип архитектуры дифференцированного обслуживания может быть развернут достаточно быстро путем соответствующей настройки таких маршрутизаторов. Более того, IP-системы сегодня понимают местоположение поля IP Precedence и, таким образом, при использовании этих битов по аналогии с поддерживающим DS оборудованием, на начальном этапе не должно возникать серьезных проблем. Иными словами, строгое соответствие DS не является обязательным даже в сети одного сервис-провайдера, если биты 0 — 2 поля DSCP используются по аналогии с битами поля IP Precedence.

4.2.1 Краткая история развития IP Precedence

Поле IP Precedence в той или иной степени является предтечей поля DS. Определения предпочтений IP и поля IP Precedence изначально были даны в [RFC791]. Значения, которые может принимать трехбитовое поле IP Precedence, могут использоваться для разных типов трафика, включая трафик сетевого управления, маршрутную информацию и различные уровни привилегий. В [RFC791] толкование поля Precedence было определено достаточно широко, как «степень важности дейтаграммы». Предполагалось, что не все значения поля IP Precedence сохраняют смысл при пересечении границ. Например, в [RFC791] было отмечено: «Уровень предпочтения Network Control (управление сетью) означает, что дейтаграмма предназначена для использования внутри сети. Реальная трактовка этого обозначения определяется местными условиями сети».

Хотя в ранних BBN IMP было реализовано использование поля Precedence, ранние коммерческие маршрутизаторы и код пересылки IP в UNIX не поддерживали эту функцию. По мере роста сложности сетей и требований пользователей производители коммерческих маршрутизаторов разработали различные варианты управления очередями пакетов, включая приоритетную обработку, которая в общем случае основывалась на правилах, закодированных в маршрутизаторах и использующих в качестве критериев адреса IP, номера протоколов IP, номера портов TCP или UDP и другие поля заголовков. Поле IP Precedence также включалось в число параметров.

Говоря коротко, можно отметить, что поле IP Precedence используется достаточно широко, но не в полном соответствии с [RFC791]. Это отмечено в [RFC1122], где указано, что использование поля IP Precedence осуществляется корректно, а конкретное распределение привилегий в [RFC791] стало достоянием истории.

4.2.2 Отображение IP Precedence в коды селекторов класса

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

4.2.2.1 Коды селектора класса

Спецификация режимов пересылки пакетов на основе значений поля DS xxx000|xx или DSCP = xxx000 без указания поля CU резервируется как набор кодов селекторов класса. PHB, которые отображаются на эти коды, должны соответствовать требованиям к PHB для селекторов класса, в дополнение к требованиям для Default PHB с кодом 000000 (параграф 4.1).

4.2.2.2 Требования к PHB для селектора класса

Мы будет говорить о коде селектора класса с большим числовым значением, нежели у другого кода селектора класса, как о коде с более высоким приоритетом. Набор PHB, отображаемых с помощью 8 битов кода селектора класса, должен обеспечивать хотя бы два независимо пересылаемых класса трафика и PHB, выбираемым по коду селектора класса, следует давать возможность маркировать пакеты кодом селектора класса с более низким приоритетом при заданных условиях и уровне трафика. Отбрасываемые пакеты рассматриваются как особый случай несвоевременной пересылки. В дополнение к этому, PHB, выбираемые по кодам 11×000, должны обеспечивать пакетам режим предпочтительной пересылки по отношению к пакетам PHB, выбранного по коду 000000 для сохранения сложившегося использования значений IP Precedence 110 и 111 для трафика протоколов маршрутизации.

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

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

Требования к PHB для селектора класса с кодом 000000 сравнимы с требованиями к принятому по умолчанию PHB (см. параграф 4.1).

4.2.2.3 Использование требований к PHB для селектора класса и совместимость с IP Precedence

Поддерживающий DS сетевой узел может быть реализован с набором из одной или множества групп PHB, совместимых с селекторами класса. В этом документе устанавливается, что набор кодов xxx000 должен отображаться на такой набор PHB. Допускается отображение множества кодов на один PHB – производитель оборудования или администратор сети может настроить сетевой узел для отображения на PHB без учета битов 3 — 5 поля DSCP для организации работы сети в соответствии со сложившейся практикой использования поля IP Precedence. Например, код 011010 может отображаться на один вариант PHB с кодом 011000.

4.2.2.4 Пример механизма реализации групп, совместимых с требованиями к PHB для селектора класса

Поддерживающие селекторы класса PHB можно реализовать множеством способов, включая строгую приоритизацию очередей, беспристрастные взвешенные очереди (WFQ12), WRR или варианты [RPS, HPFQA, DRR], очереди по классам [CBQ13]. Более предметное рассмотрение PHB и механизмов их реализации приведено в разделе 5.

Важно отметить, что эти механизмы могут быть доступны через другие PHB (возможно, стандартизованные), которые поддерживаются оборудованием конкретного производителя. Например, в будущих документах может быть стандартизована группа Strict Priority Queueing PHB для набора рекомендованных кодов. Администратор сети может настроить маршрутизаторы на выбор такой группы для кодов xxx000 в соответствии с данным документом.

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

4.3 Выводы

Этот документ определяет группу кодов xxx000, как коды селекторов класса и соответствующие этим кодам PHB должны удовлетворять требованиям к PHB для селектора класса, описанным в параграфе 4.2.2.2. Это сделано для сохранения совместимости со сложившейся практикой использования поля IP Precedence в сети Internet без снижения уровня гибкости в будущем. Код 000000 используется для принятого по умолчанию PHB и по этой причине не настраивается. Оставшиеся семь ненулевых кодов селектора класса настраиваются для расширений PHB, соответствующих требованиям параграфа 4.2.2.2.

5. Руководство по стандартизации поэтапного поведения

Стандартизуются характеристики поведения PHB, а не отдельные механизмы или алгоритмы, используемые для реализации PHB. Узел может иметь (возможно большой) набор параметров, которые могут использоваться для управления пакетами на выходном интерфейсе (например, N отдельных очередей с управляемым уровнем приоритета, размер очередей, веса при циклическом переборе, алгоритм отбрасывания, веса и пороги при отбрасывании и т. п.). Чтобы показать различия между PHB и механизмами, отметим, что PHB, совместимые с селекторами класса, могут быть реализованы с использованием нескольких механизмов, включая очереди со строгой приоритизацией, WFQ, WRR или варианты [HPFQA, RPS, DRR], CBQ [CBQ], а также комбинации этих механизмов.

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

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

Для каждого стандартизованного PHB должен предлагаться рекомендуемый код, выделенный из пространства 32 кодов (см. раздел 6). В данной спецификации пространство кодов не распределяется, чтобы обеспечить возможность развития. Таким образом, коды xxx000 оставлены свободными преднамеренно.

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

Сервис-провайдеры не обязаны использовать одинаковые механизмы и конфигурации в своей сети для предоставления дифференцированных услуг и могут выбирать конфигурационные параметры узлов в соответствии с предлагаемыми услугами и задачами управления трафиком. Ясно, что с течением времени могут появиться и широко распространиться PHB, которые особенно полезны для организации сквозной дифференциации услуг. Такие варианты поведения могут быть связаны с конкретными кодами EXP/LU14 PHB в поле DS, что позволит дифференцировать услуги через границы доменов (см. раздел 6). Такие PHB являются кандидатами для стандартизации.

Спецификации стандартизованных PHB рекомендуется задавать в соответствии с рекомендациями [ARCH].

Набор

Пространство кодов

Правила распределения

1

xxxxx0

Стандартизация

2

xxxx11

EXP/LU

3

xxxx01

EXP/LU

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

Поле DSCP внутри поля DS позволяет задать 64 различных кода. Пространство кодов делится на три части: 32 рекомендуемых кода (набор 1) выделяются путем стандартизации (Standards Action) в соответствии с [CONS], группа из 16 кодов (набор 2) резервируется для экспериментов и локального использования15 (EXP/LU) в соответствии с [CONS], а последняя группа из 16 кодов (набор 3) изначально была выделена для экспериментов и локального применения, но ее следует сохранять прежде всего для стандартного распределения по мере исчерпания набора 1. Наборы кодов показаны в таблице (x может принимать значения 0 или 1):

В этом документе выделено восемь рекомендуемых кодов (xxx000) из набора 1. Эти коды должны отображаться не на конкретные PHB, а на PHB, которые удовлетворяют, по меньшей мере, требованиям параграфа 4.2.2.2 для обеспечения минимального уровня совместимости с полем IP Precedence, определенным в [RFC791], и сложившейся практикой использования этого поля.

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

В этом разделе рассматриваются вопросы безопасности, связанные с введением дифференциации услуг, к которым, прежде всего, относятся возможные атаки на отказ служб (DoS) и возможности несанкционированного использования ресурсов (параграф 7.1). В параграфе 7.2 рассматривается дифференциация услуг при использовании IPsec, включая интеграцию с туннельным режимом IPsec и другими протоколами туннелирования. Более подробное рассмотрение вопросов безопасности, связанных с дифференциацией услуг, содержится в документе [ARCH].

7.1 Несанкционированное использование услуг и DoS-атаки

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

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

7.2 Взаимодействие с IPsec и туннелями

Протокол IPsec в соответствии с определением [ESP, AH] не включает поля DS заголовков IP в криптографические преобразования (в туннельном режиме не включается в преобразования поле внешнего заголовка IP). Следовательно, изменение поля DS в сети не оказывает влияния на сквозную защиту IPsec, поскольку такое изменение не влияет на контроль целостности IPsec. В результате IPsec не обеспечивает никакой защиты против изменения значений поля DS (т. е., MITM16-атак), поскольку такое изменение не оказывает влияния на сквозную защиту IPsec.

Туннельный режим IPsec обеспечивает защиту для поля DS инкапсулированных заголовков IP. Пакет в туннельном режиме IPsec включает два заголовка IP — внешний, который создается на входе в туннель, и инкапсулированный внутренний заголовок созданный отправителем пакета. При организации туннеля IPsec (полностью или частично) в сети с дифференцированным обслуживанием промежуточные узлы сети имеют дело с полем DS внешнего заголовка. На выходе из туннеля IPsec удаляет внешний заголовок и пересылает (при необходимости) пакет в соответствии с внутренним заголовком. Протокол IPsec требует, чтобы поле DS внутреннего заголовка не менялось при декапсуляции дабы предотвратить возможность организации атак путем изменения DS через конечную точку туннеля IPsec. Этот документ не меняет данного требования. Если внутренний заголовок IP не обрабатывается граничным узлом DS для выходного узла туннеля в домене DS, выход туннеля является граничным узлом для выходящего из туннеля трафика и поэтому должен гарантировать, что вышедший из туннеля трафик имеет приемлемый код DS.

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

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

Авторы признательны членам рабочей группы Differentiated Services за полезные дискуссии при подготовке документа.

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

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

[ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, December 1998.

[CBQ] S. Floyd and V. Jacobson, «Link-sharing and Resource Management Models for Packet Networks», IEEE/ACM Transactions on Networking, Vol. 3 no. 4, pp. 365-386, August 1995.

[CONS] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», RFC 2434, October 1998.

[DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing using Deficit Round Robin», Proc. ACM SIGCOMM 95, 1995.

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

[HPFQA] J. Bennett and Hui Zhang, «Hierarchical Packet Fair Queueing Algorithms», Proc. ACM SIGCOMM 96, August 1996.

[IPv6] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 246019, December 1998.

[RFC791] Postel, J., Editor, «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1122] Braden, R., «Requirements for Internet hosts — communication layers», STD 3, RFC 1122, October 1989.

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

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

[RPS] D. Stiliadis and A. Varma, «Rate-Proportional Servers: A Design Methodology for Fair Queueing Algorithms», IEEE/ACM Trans. on Networking, April 1998.

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

Kathleen Nichols

Cisco Systems

170 West Tasman Drive

San Jose, CA 95134-1706

Phone: +1-408-525-4857

EMail: kmn@cisco.com

Steven Blake

Torrent Networking Technologies

3000 Aerial Center, Suite 140

Morrisville, NC 27560

Phone: +1-919-468-8466 x232

EMail: slblake@torrentnet.com

Fred Baker

Cisco Systems

519 Lado Drive

Santa Barbara, CA 93111

Phone: +1-408-526-4257

EMail: fred@cisco.com

David L. Black

EMC Corporation

35 Parkwood Drive

Hopkinton, MA 01748

Phone: +1-508-435-1000 x76140

EMail: black_david@emc.com

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

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

nmalykh@gmail.com

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

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

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

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

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

1Differentiated services — дифференцированное обслуживание.

2Per-hop behavior.

3Weighted round-robin.

4См. также RFC 3260. Прим. перев.

5Differentiated services codepoint.

6Currently unused.

7См. обсуждение в разделе 6 RFC 3260. Прим. перев.

8Здесь и далее RFC цитируются по переводам, опубликованным на сайте www.protocols.ru. Прим. перев.

9Service level agreement – соглашение об уровне обслуживания. Прим. перев.

10См. раздел 7 RFC 3260. Прим. перев.

11В оригинале: «best-effort forwarding» — пересылка с использованием разумно доступных возможностей.

12Weighted fair queueing.

13Class-Based Queuing.

14Для экспериментального и локального использования.

15См. одноименный раздел в RFC 3260. Прим. перев.

16Man-in-the-middle attack — атака с перехватом и изменением данных на пути доставки при участии человека.

17Этот документ устарел и заменен RFC 4302. Прим. перев.

18Этот документ устарел и заменен RFC 4306. Прим. перев.

19Этот документ заменен RFC 8200. Прим. перев.