Патч NAT64

Интересный патч появился на tech@.

Вот что пишет Майк Белопухов:

"... Hi, here's an updated and mostly rewritten version of the diff started a while ago by the Ecdysis group (Simon Perreault, et al.) to provide a free proof of concept implementation of the draft NAT64 specification. Unfortunately their work was not finished, is not up-to-date has limited functionality and lots of bugs. We (jsg@, reyk@ and me) spent some time and produced a quality diff that addresses most of the aforementioned problems. ..."

Смысл патча заключается в том, чтобы достаточно быстро и безболезненно обеспечить переход на IPv6.
Работодатель Майка уже предлагает "Enterprise grade" продукт с одноименным патчем.

Патчи:
http://team.vantronix.net/~mike/nat64.diff
http://team.vantronix.net/~mike/pfctl.diff

Ccылка на DRAFT:
http://www.viagenie.ca/publications/2010-03-13-asiabsdcon-nat64.pdf

Продукт:
http://www.vantronix.com/products/network-migration-gateway/

Аватар пользователя A_J

То же самое, но без крыльев

А вот интересно, нет ли решений в обратную сторону - IPv4 клиенты и IPv6 сервера. Совершенно очевидно, что внутренние сети маленьких и средних компаний нет никакого резона переводить на IPv6. Это никому не нужные затраты. С другой стороны, когда у региональных регистраторов кончатся адреса, начнут появляться сервера доступные только через IPv6. И подключать новых клиентов к сети тоже станут через IPv6. Значит организациям будет нужен шлюз, который сделает доступным IPv6 снаружи для внутренних IPv4 клиентов.
Как-то так. А вот готовых решений под это дело я не вижу.

Аватар пользователя ENcrypted

Эти патчи как

Эти патчи как раз это и делают.
NAT 6-to-4, либо NAT 4-to-6.

Аватар пользователя A_J

Интересно

Просто в их драфте по ссылке написано что клиенты именно IPv6. Но может я чего не понял...

Аватар пользователя ENcrypted

В мыле Майка

В мыле Майка приведен пример 4-to-6, и далее написано что чтото подобное можно сделать в обратную сторону.
Делать патчи работающие только в одном направлении нету смысла - недоделка.

Более того, взглянув на код(pfctl rules syntax), могу зказать что работать он должен в обоих направлениях:
af-to inet
af-to inet6.

Аватар пользователя A_J

Я вижу две

Я вижу две проблемы в конверсии 4-to-6. С одной стороны, чисто политически RFC 4966 предлагает перевести RFC 2766 в статус исторического. Т.е. от трансляции типа NAT-PT предполагается вовсе отказаться.

Техническая сложность есть в доступе к IPv6 хостам с IPv4. Нужна жосткая связка pf с DNS, который будет мапить имена резолвящиеся только в IPv6 в каки-то фейковые адреса IPv4 (например, 10.x.y.z).

При мапинге 4to6 таких проблем не возникает, поскольку IPv4 можно рассмотреть как подмножество IPv6, но не наоборот. Я согласен с доводами RFC 4966 о том, что DNS-ALG вносит много проблем (невозможность долго использовать адрес и т.п.) но все же это лучше чем ничего.