RFC: 3168
Оригинал: The Addition of Explicit Congestion Notification (ECN) to IP
Предыдущие версии: RFC 2481
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Николай Малых

9. Инкапсулированные пакеты

9.1. Пакеты IP, инкапсулированные в IP

Инкапсуляция заголовков пакетов IP в туннели используется во многих случаях, включая IPsec и IP in IP [RFC2003]. В этом разделе рассматриваются вопросы, связанные со взаимодействием между ECN и IP, а также описаны два дополнительных решения. Это обсуждение дополняется рассмотрением в RFC 2983 взаимодействия между дифференцированным обслуживанием (DifServ) и различными формами туннелей IP [RFC 2983], а также использования в DifServ оставшихся 6 битов заголовка IP, не занятых ECN (см. Рисунок 2 в разделе 5).

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

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

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

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

В результате возникают два жизнеспособных варианта поведения поддерживающих ECN соединений через туннели IP, включая IPsec:

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

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

Одной из задач данного документа является определение компромисса между полнофункциональным и ограниченным вариантами. Полное обсуждение потенциальных эффектов враждебного изменения поля ECN приведено в разделах 18 и 19.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.