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

Остаточное развертывание IPv4 ( 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, тогда как 4-й, по крайней мере, до сих пор указан в экспериментальном RFC (см. раздел «История» ниже): выбранный механизм остается чисто внутренним для каждого домена.

Принципы

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

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

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

История

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

без сохранения состояния Следующим был предложен другой подход A+P , названный dIVI. ^{[ 10 ]} Вместо инкапсуляции использовались две последовательные трансляции (с IPv4 на IPv6, а затем наоборот), основанные на существующих SIIT односторонних трансляциях RFC 2765. По сравнению с инкапсуляцией он имел преимущество, заключающееся в том, что проверки пакетов IPv6 можно было применять к преобразованным пакетам IPv4 UDP и TCP, но из-за ограничений SIIT не имел полной совместимости с фрагментацией IPv4 (и, следовательно, как упоминалось выше, совместимость с путевым MTU Discovery рекомендовалась). в 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 развернул четвертое место в своем эксперименте FTTH в «зонах с меньшей плотностью населения», начиная с декабря 2015 года. Реализация модели A+P подразумевает присвоение четырех смежных диапазонов портов разным клиентам для каждого IPv4. адрес. Также известно, что Free был первым разработчиком 6rd . ^{[ 17 ]}

Ссылки

^ Ву, Дж.; Цюи, Ю.; Мец, К.; Розен, Э. (2009). «Сценарий сетки IPv4-over-IPv6» . дои : 10.17487/RFC5565 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ «Есть ли в Linux эквивалент Windows PMTU Blackhole Router Discovery?» .
^ Jump up to: ^а ^б Депре, Р.; Пенно, Р.; Ли, Ю.; Чен, Г.; Чен, М.; Чен, М. (2015). Цзян, С. (ред.). «Обратимая трансляция пакетов на входах и выходах из домена» . дои : 10.17487/RFC7600 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ Дугал, Д.; Пиньятаро, К.; Данн, Р. (2011). в RFC» «Компромиссы при проектировании – дои : 10.17487/RFC6192 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ Дек, В.; Ли, Х.; Бао, К.; Мацусима, С.; Мураками, Т.; Мураками, Т.; Тейлор, Т. (2015). Троан, О.; Тейлор, Т. (ред.). «Получение фрагментов IPv4 на границах домена MAP (случай MAP-E)» . дои : 10.17487/RFC7597 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ Ли, Х.; Бао, К.; Троан, О.; Мацусима, С.; Мураками, Т.; Мураками, Т. (2015). Дек, В. (ред.). «Получение фрагментов IPv4 на границах домена MAP (случай MAP-T)» . дои : 10.17487/RFC7599 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ Депре, Р.; Пенно, Р.; Ли, Ю.; Чен, Г.; Чен, М.; Чен, М. (2015). Цзян, С. (ред.). «Порты фрагментов, адресованные CE с общими адресами (4-й случай)» . CiteSeerX 10.1.1.697.6541 . дои : 10.17487/RFC7600 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ «Публичные адреса IPv4 и префиксы IPv4E в доменах только для IPv6», 4-е место . Ietf Datatracker .
^ «Остаточное развертывание IPv4 в сетях IPv6-Service (4-й) ISP-NAT стало необязательным» . Ietf Datatracker .
^ "draft-xli-behave-divi-02" . Ietf Datatracker .
^ "draft-ietf-softwire-map-00" . Ietf Datatracker .
^ Jump up to: ^а ^б ^с «IETF-84 — Рабочая группа по программному обеспечению — Протокол собрания» .
^ "draft-ietf-softwire-map-00" .
^ «Четвертый отчет о реализации» .
^ Jump up to: ^а ^б «Рабочая группа IETF Softwires (softwire)» .
^ «[Программное обеспечение] MAP-T для отслеживания стандартов» .
^ Шампо, Гийом (15 февраля 2016 г.). «Бесплатно можно назначить один и тот же IP-адрес нескольким абонентам» . Нумерама (на французском языке) . Проверено 29 февраля 2016 г.

[1] Ву, Дж.; Цюи, Ю.; Мец, К.; Розен, Э. (2009). «Сценарий сетки IPv4-over-IPv6» . дои : 10.17487/RFC5565 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[2] «Есть ли в Linux эквивалент Windows PMTU Blackhole Router Discovery?» .

[reversible_translation-3] Jump up to: ^а ^б Депре, Р.; Пенно, Р.; Ли, Ю.; Чен, Г.; Чен, М.; Чен, М. (2015). Цзян, С. (ред.). «Обратимая трансляция пакетов на входах и выходах из домена» . дои : 10.17487/RFC7600 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[4] Дугал, Д.; Пиньятаро, К.; Данн, Р. (2011). в RFC» «Компромиссы при проектировании – дои : 10.17487/RFC6192 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[5] Дек, В.; Ли, Х.; Бао, К.; Мацусима, С.; Мураками, Т.; Мураками, Т.; Тейлор, Т. (2015). Троан, О.; Тейлор, Т. (ред.). «Получение фрагментов IPv4 на границах домена MAP (случай MAP-E)» . дои : 10.17487/RFC7597 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[6] Ли, Х.; Бао, К.; Троан, О.; Мацусима, С.; Мураками, Т.; Мураками, Т. (2015). Дек, В. (ред.). «Получение фрагментов IPv4 на границах домена MAP (случай MAP-T)» . дои : 10.17487/RFC7599 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[7] Депре, Р.; Пенно, Р.; Ли, Ю.; Чен, Г.; Чен, М.; Чен, М. (2015). Цзян, С. (ред.). «Порты фрагментов, адресованные CE с общими адресами (4-й случай)» . CiteSeerX 10.1.1.697.6541 . дои : 10.17487/RFC7600 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[8] «Публичные адреса IPv4 и префиксы IPv4E в доменах только для IPv6», 4-е место . Ietf Datatracker .

[9] «Остаточное развертывание IPv4 в сетях IPv6-Service (4-й) ISP-NAT стало необязательным» . Ietf Datatracker .

[10] "draft-xli-behave-divi-02" . Ietf Datatracker .

[11] "draft-ietf-softwire-map-00" . Ietf Datatracker .

[Minutes-12] Jump up to: ^а ^б ^с «IETF-84 — Рабочая группа по программному обеспечению — Протокол собрания» .

[13] "draft-ietf-softwire-map-00" .

[14] «Четвертый отчет о реализации» .

[Softwire-15] Jump up to: ^а ^б «Рабочая группа IETF Softwires (softwire)» .

[16] «[Программное обеспечение] MAP-T для отслеживания стандартов» .

[17] Шампо, Гийом (15 февраля 2016 г.). «Бесплатно можно назначить один и тот же IP-адрес нескольким абонентам» . Нумерама (на французском языке) . Проверено 29 февраля 2016 г.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]