12. Список требуемых изменений для IP и TCP
В этом документе определено использование для ECN двух битов заголовка IP. Код not-ECT показывает, что транспортный протокол будет игнорировать код CE. Этот код является принятым по умолчанию значением кода ECN. Коды ECT показывают, что транспортный протокол хочет и может участвовать в работе ECN.
Маршрутизатор устанавливает код CE для индикации перегрузки конечным узлам. Маршрутизаторам недопустимо сбрасывать код CE в заголовках пакетов.
Для поддержки ECN в протокол TCP требуется внести три изменения — это фаза организации соединения и два новых флага в заголовке TCP. Флаг ECN-Echo используется получателем данных для информирования отправителя о получении пакета CE. Флаг снижения размера окна насыщения (CWR) используется отправителем данных для информирования получателя о снижении размера окна насыщения.
При использовании ECN (явное уведомление о перегрузке) требуется, чтобы индикаторы насыщения, генерируемые в туннеле IP, не терялись на выходе из туннеля. Мы вносим незначительные изменения в протокол IP для обработки поля ECN при инкапсуляции и декапсуляции, позволяющие потокам, проходящим через туннели IP, использовать ECN.
В туннелях для ECN определяются две опции:
Опция ограниченной функциональности, при использование ECN внутри туннеля IP отключается путем установки в поле ECN значения not-ECT и сохранения внутреннего заголовка при декапсуляции.
Пофункциональная опция, когда в поле ECN внешнего заголовка может использоваться код not-ECT или один из кодов ECT в зависимости от значения поля ECN во внутреннем заголовке. При декапсуляции код CE копируется во внутренний заголовок, если этот код присутствует во внешнем аголовке, а во внутреннем установлен один из кодов ECT.
Для туннелей IPsec в этом документе также определен необязательный атрибут защитной ассоциации (SA), управляющий согласованием использования ECN в туннеле IPsec и необязательное поле SAD для индикации возможности использования ECN в туннельном режиме для SA. Требуемые для использования ECN изменения туннелей IPsec вносят изменения в документ RFC 4301 [RFC4301], определяющий архитектуру IPsec и задающий некоторые аспекты реализации. Новый атрибут IPsec SA дополняет атрибуты, определенные в параграфе 4.5 [RFC4306].
Этот документ отменяет действие RFC 2481 «A Proposal to add Explicit Congestion Notification (ECN) to IP» (Предложение по добавлению явных уведомлений оперегрузке (ECN) в протокол IP), который определял ECN в качестве экспериментального протокола для сообщества Internet. В оставшейся части этого параграфа описаны связи настоящего документа с его предшественником.
RFC 2481 включает краткое обсуждение использования ECN с инкапсулированными пакетами, в котором отмечено, что спецификация IPsec на тот момент (январь 1999) говорит о невозможности безопасного использования ECN через туннели IPsec. В RFC 2481 также описаны изменения, которые нужно было сделать в спецификации туннелей IPsec для обеспечения совместимости с ECN.
В этом документе учтены работы, выполненные с момента публикации RFC 2481. Во-первых, детально описаны изменения для туннелей IPsec и подробно рассмотрено влияние ECN на безопасность (разделы 18 и 19). Во-вторых, рассмотрение туннелей IPsec расширено для всех туннелей IP. Поскольку старые туннели IP не совместимы с потоками, использующими ECN, развертывание ECN в сети Internet оказываало сильное давление на процессы обновления старых реализаций туннелей до совместимых с ECN версий на основе использования опции полной или ограниченной функциональности.
В этом документе не рассматриваются вопросы использования ECN в туннелях других протоколов (не IP) типа MPLS, GRE, L2TP или PPTP. В настоящее время предварительные документы по включению поддержки ECN в MPLS находятся в стадии разработки.
В-третьих, после публикации RFC2481 были описаны процедуры ECN для повторно передаваемых пакетов данных, когда код ECT при повторной передаче устанавливать не следует. Мотивом отказа от использования кодов при повторе передачи послужило желание предотвратить возможные атаки на службы (DoS) для существующих соединений TCP. Некоторые ранние реализации TCP с поддержкой ECN могут не соответствовать (новым) требованиям по отказу от установки кода ECT в повторно передаваемых пакетах; мы полагаем, что на практике это не вызовет существенных проблем.
Этот документ также несколько расширяет спецификацию использования пакетов SYN для согласования ECN. Некоторые ранние реализации TCP с поддержкой ECN могут не соответствовать заданным здесь требованиям, но мы полагаем, что это не вызовет проблем в организации и производительности соединений TCP в которых участвуют реализации с различными возможностями.
Этот документ также включает спецификацию кода ECT(1), который может использоваться протоколом TCP, как часть реализации ECN nonce.