[kww]

Добрый день.

Подскажите, есть ли у кого опыт 1:1 NAT IPv4 в IPv6 ?

Смысл этого действа в поддержке "старого" оборудования.

например выдать пользователю сеть 10..0.0.0/24 и 1:1 странслировать в IPv6 ?

Бывают ли для этого специализированные железки ?

Есть смысл этого действа или есть более грамотный путь NOT IPv6 Ready ?

Изменено 20 января, 2011 пользователем kww

[Ivan_83]

Вы думали прежде чем написать?)

 

Какой пользователю толк с доступа к одной не полной /32 подсести ИПв6 интернета?

Не полной, потому что от туда вычтут 127/8, 169..., 10/8, 172.. 224/8 - короче зарезервированные подсети.

И что делать с частью интернета /32, когда на одного пользователя/дом рекомендуют /64 давать, как минимальную единицу?

 

 

Вот транслировать кусок в6 в в4 смысл имеет, и технически это не сильно сложно.

Но и это имеет смысл для того чтобы админить старое оборудование с хостов у котороых только в6.

Или например принтер сетевой/принтсервер только в4, а печатать хочется всем, а у всех только в6, и то есть другие варианты выхода из этого положения.

[kww]

Вот транслировать кусок в6 в в4 смысл имеет, и технически это не сильно сложно.

Но и это имеет смысл для того чтобы админить старое оборудование с хостов у котороых только в6.

Или например принтер сетевой/принтсервер только в4, а печатать хочется всем, а у всех только в6, и то есть другие варианты выхода из этого положения.

Какие есть еще варианты допустим с тем-же старым принтсервером ?

[marikoda]

Подозреваю, что можно, например, для application level сделать прокси.

 

Например, юзер из "серой" сети резолвит запись AAAA, которая преобразуется в фиктивную A по определенной таблице.

 

И если он обращается к http (imap,pop3 и т.п.), то попадает на прокси ( или nat, редиректор портов и т.п.) , который уже соединяет его с хостом в ipv6.

 

Соответственно, таблица трансляции через некоторое время очищается (например, через ttl той DNS записи, которая отдаётся на подмену AAAA)

Изменено 20 января, 2011 пользователем marikoda

[Ivan_83]

Какие есть еще варианты допустим с тем-же старым принтсервером ?

Конкретно с ним - держать сервер с двойным стёком, на котором настроить службу печати либо просто редирект отдельных портов.

Я планирую дописать ноду к фряхе для в4, отдельный от ядра в4 стёк, чтобы формально можно было иметь только в6 в системе, но получать доступ и к в4.

 

 

 

Подозреваю, что можно, например, для application level сделать прокси.

 

Например, юзер из "серой" сети резолвит запись AAAA, которая преобразуется в фиктивную A по определенной таблице.

 

И если он обращается к http (imap,pop3 и т.п.), то попадает на прокси ( или nat, редиректор портов и т.п.) , который уже соединяет его с хостом в ipv6.

 

Соответственно, таблица трансляции через некоторое время очищается (например, через ttl той DNS записи, которая отдаётся на подмену AAAA)

Вряд ли такое будет, слишком трудоёмко.

 

[marikoda]

Вряд ли такое будет, слишком трудоёмко.

Нечто подобное уже есть в Linux для ipv4 - это conntrack и всякие nat модули для ftp, sip, gre и т.п.

 

[rm_]

Какие есть еще варианты допустим с тем-же старым принтсервером ?

Либо NAT64, либо простой юзерспейсный перенаправитель соединений типа 6tunnel.

[Ivan_83]

Нечто подобное уже есть в Linux для ipv4 - это conntrack и всякие nat модули для ftp, sip, gre и т.п.

Это говорит о том, что вы сами руками протоколы не щупали ни разу, а только админите потоки трафика.

 

То что у вас в линухе называется коннтрак модули во фре это либы от либалиас.

Это костыли чтобы правильно натить протоколы у которых л3 адрес передаётся в самом протоколе и необходим для его правильной работы.

Они меняют 1 ип адрес на другой, в некоторых случаях кое что ещё делают.

При том, что ип адреса имеют одинаковую длину.

 

 

А теперь: что делать когда длинна ип адреса разная?)

Или ещё лучше: как в ДНС АААА в А превращать?

 

Ещё интереснее, это то, что в хтмл прочем внедрённом и связанном с ним коде, коий бывает и на джаве, и даже зашифрованный, бывает зашит ип адрес, вместо днс имени.

Те придётся парсить регэкспом кучу всего и менять.

А поскольку заменяется на более длинное, то это ещё доп расходы памяти и ресурсов.

 

 

 

Короче говоря: даже NAT64 вряд ли можно использовать в операторском продакшене, либо сразу заявлять что ваши проблемы от пользования этим мы решать не станем: работает - повезло, не работает - так и должно быть.

Хотя это вполне простой, прямой и понятный костыль, с вполне понятными проблемами и решениями/их отсутствием.

NAT46 - полное глюкалово (если привязываться к днс для трансляции), либо крайне ограниченное решение.

 

 

По поводу хтмл, с не вшитыми ип адресами есть идея:

достаточно чтобы шлюз был с двойным стёком, и просто держать на нём прокси, хотя бы тот же сквид.

Если предполагается что в6 клиент хочет к в4 по ип подключится, то возможно нужно будет мутить реврайтер адресов в сквиде, а клиент будет писать что нибудь типа: 192.168.0.1.v4 - чтобы браузер у прокси спрашивал по имени и без недоумений.

[marikoda]

То что у вас в линухе называется коннтрак модули во фре это либы от либалиас.

Это костыли чтобы правильно натить протоколы у которых л3 адрес передаётся в самом протоколе и необходим для его правильной работы.

Они меняют 1 ип адрес на другой, в некоторых случаях кое что ещё делают.

При том, что ип адреса имеют одинаковую длину.

Не соглашусь. Хелперы, например, для ftp или sip меняют один адрес на другой в текстовом протоколе, т.е. длина вполне может оказываться разной.

 

А теперь: что делать когда длинна ип адреса разная?)

Или ещё лучше: как в ДНС АААА в А превращать?

Выше про это писал: держать таблицу трансляции вида

AAAA запись - "серый" адрес и чистить ее через некоторое время.

Что-то вроде NAPT, то еще круче и сложнее :)

 

Ещё интереснее, это то, что в хтмл прочем внедрённом и связанном с ним коде, коий бывает и на джаве, и даже зашифрованный, бывает зашит ип адрес, вместо днс имени.

Те придётся парсить регэкспом кучу всего и менять.

А поскольку заменяется на более длинное, то это ещё доп расходы памяти и ресурсов.

В 95% случаев там будет доменное имя, в остальных можно сделать трансляцию вручную.

 

Короче говоря: даже NAT64 вряд ли можно использовать в операторском продакшене, либо сразу заявлять что ваши проблемы от пользования этим мы решать не станем: работает - повезло, не работает - так и должно быть.

Хотя это вполне простой, прямой и понятный костыль, с вполне понятными проблемами и решениями/их отсутствием.

NAT46 - полное глюкалово (если привязываться к днс для трансляции), либо крайне ограниченное решение.

Глюкало - согласен. Но тут же вроде разговор о proof of concept ?

По поводу хтмл, с не вшитыми ип адресами есть идея:

достаточно чтобы шлюз был с двойным стёком, и просто держать на нём прокси, хотя бы тот же сквид.

Если предполагается что в6 клиент хочет к в4 по ип подключится, то возможно нужно будет мутить реврайтер адресов в сквиде, а клиент будет писать что нибудь типа: 192.168.0.1.v4 - чтобы браузер у прокси спрашивал по имени и без недоумений.

Ну это и так понятно.

Дело ведь в том, что не только http прокотол используются.

 

[rm_]

Или ещё лучше: как в ДНС АААА в А превращать?

Это проблема решённая, см. DNS64 (который используется в комплекте с NAT64).

AAAA для не имеющих её хостов придумывается на ходу из "NAT64 prefix + IPv4".

 

Ещё интереснее, это то, что в хтмл прочем внедрённом и связанном с ним коде, коий бывает и на джаве, и даже зашифрованный, бывает зашит ип адрес, вместо днс имени.

Тут да, ничего не поделаешь.

 

Те придётся парсить регэкспом кучу всего и менять.

А поскольку заменяется на более длинное, то это ещё доп расходы памяти и ресурсов.

Во-первых малореальная перспектива, гнать весь поток HTTP через умный парсер на регэкспах, чтобы тот не захлебнулся при этом (или отдельный кластер специально под эту задачу?)

Во-вторых, лезти руками чего-то реплейсить в пользовательском трафике - слишком высока вероятность поломать кучу вещей. Что если я читаю страницу, где просто перечисляются через запятую ради информации какие-то IPv4-адреса. Или мне на личный ящик прислали E-Mail с инструкциями по подключению к офисному почтовому серверу (из офиса с другого провайдера). Что с контрольными суммами, GPG-подписями? И т.д.

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

Впрочем и без них в целом можно жить, см. http://tools.ietf.org/html/draft-arkko-ipv...y-experience-02

Точнее, IPv4-адреса в HTML - самая меньшая из проблем в конфигурации v6-only + NAT64. Большая - старый v4-only софт.

 

Короче говоря: даже NAT64 вряд ли можно использовать в операторском продакшене

Абсолютно верно, в одиночку нельзя, но при желании можно как дополнение к dual stack.

Изменено 22 января, 2011 пользователем rm_

[marikoda]

Или ещё лучше: как в ДНС АААА в А превращать?

Это проблема решённая, см. DNS64 (который используется в комплекте с NAT64).

AAAA для не имеющих её хостов придумывается на ходу из "NAT64 prefix + IPv4".

Мы обсуждали вариант строго обратный, как для малого числа клиентов, которые умеют только ipv4 (старое железо, старые OS и т.п.) обеспечить доступ к хостам, умеющим только ipv6.

Т.е. если в nat64 клиент имеет адрес ipv6, а сервер ipv4, то в данном случае - наоборот.

Изменено 22 января, 2011 пользователем marikoda

[Ivan_83]

Не соглашусь. Хелперы, например, для ftp или sip меняют один адрес на другой в текстовом протоколе, т.е. длина вполне может оказываться разной.

Если новая меньше - вполне можно забить чем нибудь типа пробелов.

 

 

Выше про это писал: держать таблицу трансляции вида

AAAA запись - "серый" адрес и чистить ее через некоторое время.

Что-то вроде NAPT, то еще круче и сложнее :)

Видел.

Это не поможет тем, кто ДНС не использует.

Не считая что кроме А записей в днс есть другие типы записей с адресами.

Но для простых случаев, типа емаил клиентов, должно сработать.

 

 

 

В 95% случаев там будет доменное имя, в остальных можно сделать трансляцию вручную.

Только если для себя любимого.

 

 

Ну это и так понятно.

Дело ведь в том, что не только http прокотол используются.

Кто не обучен через хттп/сокс(?) прокси работать - тот и не сможет работать.

 

 

Во-первых малореальная перспектива, гнать весь поток HTTP через умный парсер на регэкспах, чтобы тот не захлебнулся при этом (или отдельный кластер специально под эту задачу?)

Во-вторых, лезти руками чего-то реплейсить в пользовательском трафике - слишком высока вероятность поломать кучу вещей. Что если я читаю страницу, где просто перечисляются через запятую ради информации какие-то IPv4-адреса. Или мне на личный ящик прислали E-Mail с инструкциями по подключению к офисному почтовому серверу (из офиса с другого провайдера). Что с контрольными суммами, GPG-подписями? И т.д.

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

Впрочем и без них в целом можно жить, см. http://tools.ietf.org/html/draft-arkko-ipv...y-experience-02

Точнее, IPv4-адреса в HTML - самая меньшая из проблем в конфигурации v6-only + NAT64. Большая - старый v4-only софт.

Я и не думал даже применять такой изврат с регэкспами для продакшена в исп, это максимум на шлюзе дома/офисе, или для тех персонала чтобы со старым железом работать.

в4 адреса, отличные от адреса откуда идёт траф по идее трогать и не нужно. А нужно править только которые http://ip, чтобы корректно веб интерфейс отрабатывал.

Старый в4 софт - сможет относительно относительно без проблем;но жить в локалках

 

[rm_]

чтобы со старым железом работать.

Только что решал как раз эту проблему.

Имеется: точка доступа, не уразумеющая IPv6. Зато имеющая v4-адрес 192.168.1.1.

На сервере в одной с нею сети выполняю:

ADDR=2001:470:989e::1:1
ip addr add $ADDR/64 dev eth0 preferred_lft 0
6tunnel -L $ADDR -6 -4 80 ::ffff:192.168.1.1 80

Добавляю в DNS:

wrv200  86400  IN  AAAA  2001:470:989e::1:1

Всё, теперь эту ТД можно админить по IPv6 из любой точки Интернета (если бы это было разрешено моим файрволлом).

http://ompldr.org/vNzQ3dA/2011-01-23T155704Z-wrv200.png

 

Могло бы не получиться, если бы ТД в генерируемом HTML упоминала свой буквальный v4-адрес - но к счастью она этого не делает, покликал по страницам веб-интерфейса, все пути ссылок и отправки форм везде относительные, всё работает.

Изменено 23 января, 2011 пользователем rm_

[Ivan_83]

Я думаю просто транслятор/натилку поставить 6-4, без фаерволинга и пр.

Нода с автономным от ядра в4 стёком позволит в ядре в4 не держать, лет через 5-10 это будет актуально.

Как представляю можно будет анонсить в сеть этот транслятор как дефолтшлюз для определённого префикса.

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

 

 

Вообще, думаю китайцы наклепают таки коробочек в6-4, рублей по тыще.

Мозгов там особо не нужно, памяти не нужно (таблицу трансляций держать нет необходимости), настроек почти никаких.