Остаточное развертывание IPv4

IPv4 Residual Deployment ( 4rd ) — это механизм перехода IPv6 для поставщиков интернет-услуг для развертывания интернет-протокола версии 6 (IPv6) при сохранении обслуживания IPv4 для клиентов. Протокол и примеры приложений указаны в RFC 7600.

Остаточное развертывание IPv4 имеет три основные функции:

• Топология сети: между двумя конечными точками пакеты IPv4 проходят по тем же прямым маршрутам , что и пакеты IPv6. ^[1]
• Общие адреса IPv4: чтобы справиться с неизбежной нехваткой адресов IPv4, нескольким клиентам можно назначить общий адрес IPv4, при этом каждому из них будут назначены отдельные наборы портов TCP/UDP (применение общей модели A+P RFC 6346).
• Работа без сохранения состояния: преобразования пакетов IPv4 в пакеты IPv6 при входе в домен и обратно при выходе из домена не имеют состояния (т. е. не требуют сохранения состояния для каждого клиента в пограничных узлах домена).

По сравнению с другими механизмами, указанными IETF, имеющими те же основные характеристики, т. е. MAP-E (RFC 7597, RFC 7598, RFC 2473) и MAP-T (RFC 7599, RFC 7598, RFC 6145), его отличительной особенностью является то, что он одновременно поддерживает:

• Полная прозрачность фрагментации IPv4: с этой функцией сохраняется поддержка обнаружения MTU пути RFC 4821, рекомендованного в RFC 6349. Без нее, где бы брандмауэры ни фильтровали пакеты ICMP, конечные системы, поддерживающие RFC 4821 ^[2], теряют возможность использовать преимущества путей, поддерживающих большие пакеты .
• Применимость проверок пакетов IPv6 к IPv4: при прохождении доменов, поддерживающих только IPv6, преобразованные пакеты IPv4 являются обычными пакетами IPv6, содержимое которых не изменяется и является действительным в IPv6. ^[3] Таким образом, фильтры IPv6, которые выполняются в домене, поддерживающем только IPv6, например, для списков контроля доступа , веб-кэшей , глубоких проверок пакетов , неявно и автоматически эффективны для пакетов IPv4, проходящих через домен.

MAP-E поддерживает только первый вариант, а MAP-T — только второй.

Если интернет-провайдер хочет предложить остаточный сервис IPv4 в домене, поддерживающем только IPv6, и предоставляет оборудование, устанавливаемое на территории клиента , всем своим клиентам этого домена, он может выбрать любой из MAP-E, MAP-T или 4rd, при этом осознавая, что MAP-E и MAP-T указаны в документах RFC, относящихся к стандартам, тогда как 4rd, по крайней мере, пока указан в экспериментальном документе RFC (см. раздел «История» ниже): выбранный механизм остается чисто внутренним для каждого домена.

Ключом, позволяющим объединить прозрачность фрагментации IPv4 с глубокой проверкой пакетов IPv6 в единой конструкции, является использование обратимой трансляции пакетов на входах и выходах домена. ^[3] Это возможно, поскольку заголовки пакетов IPv6, должным образом дополненные заголовками фрагментов при необходимости, достаточно велики, чтобы закодировать в них, специальным образом, подробно описанным в RFC 7600, всю полезную информацию заголовков IPv4. (Это было невозможно в 6rd , механизме туннелирования для IPv6 через домены, поддерживающие только IPv4, поскольку заголовки IPv4 слишком малы, чтобы содержать всю информацию заголовков IPv6).

Параметры уровня IP IPv4 не поддерживаются в 4-й версии, но это не имеет практических последствий, поскольку конечные системы уже адаптированы к тому факту, что по соображениям безопасности параметры уровня IPv4 фильтруются многими маршрутизаторами. ^[4]

Другой вопрос, в котором 4-я спецификация выходит за рамки MAP-E и MAP-T, касается фрагментированных датаграмм IPv4. В спецификациях MAP-E и MAP-T единственное полностью описанное поведение включает повторную сборку датаграмм при входе в домен перед пересылкой. ^{[5] [6]} Для улучшения воспринимаемой пользователем производительности, для уменьшения обработки входа в домен и для уменьшения возможностей атак 4-я спецификация включает алгоритм, посредством которого полученные фрагменты больших датаграмм пересылаются один за другим на лету. ^[7]

Первая "4-я" спецификация, в отличие от текущей спецификации RFC 7600, использовала инкапсуляцию IPv4 в пакетах IPv6, единственный известный на тот момент подход к туннелированию, гарантирующий полное сохранение IPv4 в доменах только IPv6. Это было первое предложение, которое объединило отображение адресов без сохранения состояния, топологию сетки и A+P . ^{[8] [9]}

Затем был предложен другой подход без сохранения состояния — A+P , названный dIVI. ^[10] Вместо инкапсуляции он использовал два последовательных перевода (из IPv4 в IPv6 и затем наоборот) на основе существующих односторонних переводов SIIT RFC 2765. По сравнению с инкапсуляцией он имел преимущество в том, что делал проверки пакетов IPv6 применимыми к транслируемым пакетам UDP и TCP IPv4, но из-за ограничений SIIT не имел полной совместимости с фрагментацией IPv4 (и, следовательно, как упоминалось выше, совместимости с обнаружением MTU пути, рекомендованным в RFC 6349).

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

• Один предложил переименовать 4-е решение инкапсуляции в MAP-E , переименовать двойную трансляцию SIIT в MAP-T , и связать их в объединенную спецификацию под названием MAP . ^[11] Идея заключалась в том, что для удовлетворения цели стандартной уникальности спецификация, имеющая два варианта (среди которых выбор остается необходимым для каждого домена только IPv6), может считаться эквивалентной одному стандарту. Но консенсуса по этой интерпретации достигнуто не было. ^[12]
• Другой был основан на открытии того, что, как упоминалось выше, модернизированный алгоритм двойной трансляции IPv4-IPv6 был возможен, что сочетало применимость проверок пакетов IPv6 к IPv4, как MAP-T, и полную совместимость с фрагментацией IPv4, как MAP-E. Поскольку аббревиатура "4rd" больше не использовалась для решения инкапсуляции, это решение было названо 4rd . Было сделано предложение использовать этот подход для уникального стандарта. ^[13] Но, несмотря на проверку его принципа на реализации, ^[14] не вызвал интереса у сторонников ни MAP-E, ни MAP-T. ^[12]

После долгих дебатов рабочая группа Softwire ^[15] в августе 2012 года решила, что стандартизирован будет только MAP-E, а работа может быть продолжена как над 4rd, так и над MAP-T, но только в качестве экспериментальной. ^[12]

Наконец, в декабре 2014 года рабочая группа Softwire ^[15] изменила свое предыдущее решение и решила включить MAP-T в список стандартов параллельно с MAP-E, при условии, что примечание в MAP-T RFC будет указывать на его несовместимость с обнаружением MTU-пути RFC 4821. ^[16]

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

Французский интернет-провайдер Free , как полагают, развернул 4rd для своего эксперимента FTTH в «менее плотных районах», начиная с декабря 2015 года. Реализация модели A+P подразумевает присвоение четырех смежных диапазонов портов разным клиентам для каждого адреса IPv4. Free также был известен как первый реализатор 6rd . ^[17]