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

Механизмы перехода IPv6
Стандарты Track
Экспериментальный
Информационная
Черновики
Не рекомендуется

Остаточное развертывание IPv4 (4-й) является Механизм перехода IPv6 за Интернет-провайдеры для развертывания Интернет-протокол версии 6 (IPv6), поддерживая обслуживание клиентов IPv4. Протокол и примеры приложений указаны в RFC 7600.

Функции

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

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

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

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

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

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

История

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

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

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

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

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

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

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

Реальное развертывание

Французский интернет-провайдер Свободный считается развернутым 4-м для своего эксперимента FTTH в «менее плотных районах», начиная с декабря 2015 года. А + П Модель подразумевает отнесение четырех непрерывных диапазонов портов к разным клиентам для каждого IPv4-адреса. Free также был известен как первый разработчик 6-й.[17]

Рекомендации

  1. ^ "Сценарий ячеистой сети IPv4-over-IPv6".
  2. ^ «Есть ли в Linux аналог Windows PMTU Blackhole Router Discovery?».
  3. ^ а б «Обратимые трансляции пакетов на входе и выходе из домена».
  4. ^ «Компромиссы дизайна - в RFC 6192».
  5. ^ «Получение фрагментов IPv4 на границах домена MAP (случай MAP-E)».
  6. ^ «Получение фрагментов IPv4 на границах домена MAP (случай MAP-T)».
  7. ^ «Порты фрагментов, адресованные CE с общим адресом (4-й случай)».
  8. ^ "Общедоступные адреса IPv4 и префиксы IPv4E в доменах только для IPv6 4rd".
  9. ^ «Остаточное развертывание IPv4 в сетях IPv6-Service (4rd) ISP-NAT сделано необязательно».
  10. ^ "черновик-xli-поведение-диви-02".
  11. ^ "draft-ietf-softwire-map-00".
  12. ^ а б c «IETF-84 - Softwire WG - Протокол собрания».
  13. ^ "draft-ietf-softwire-map-00".
  14. ^ «4-й отчет о реализации».
  15. ^ а б «Рабочая группа IETF Softwires (softwire)».
  16. ^ "[Softwires] MAP-T в соответствие со стандартами".
  17. ^ Шампо, Гийом (15 февраля 2016 г.). "Бесплатный атрибут адреса электронной почты для дополнительных абонентов". Numerama (На французском). Получено 29 февраля 2016.