IPv6 и NAT6:6

Решил просвятиться

А ты каким святым решил стать? Мучеником или страстотерпцем?

IPv6
Мучеником или страстотерпцем

Вся суть.

если ты всё равно ходишь через VPN, то ходи и в IPv6 через VPN, какая тебе разница

1) Свободная связность всех устройств, не ограниченная натом важнее.

2) Можно на каждое исходящее соединение новый глобальный адрес назначать, IPv4 так не может

1) Свободная связность всех устройств, не ограниченная натом важнее.

важнее, но что мешало им оставить NAT «на всяуий случай»?

2) Можно на каждое исходящее соединение новый глобальный адрес назначать, IPv4 так не может

И толку, если все эти адреса будут из одной подсети /64?

И толку, если все эти адреса будут из одной подсети /64?

а на IPv4 с одного адреса

Но ipv4 сейчас можно спрятать общественными vpn, а в ipv6 такой возможности нет. Об этом и тема...

почему нет, заходишь через VPN, VPN назначает тебе адрес из /64 VPN провайдера

Гм, белка-истеричка задумался...

А что с IPv6, на микроте у него вообще нет вкладки NAT, в интернете пишут что реализации NAT6:6 в стандарте нет (хотя технически он не должен быть сложнее NAT4:4), но может найдутся упоротые вендеры которые напишут свою.

Как уже написали выше, для работы VPN через IPv6 нам не обязательно нужен NAT. Устройства могут получать реальные IPv6 от VPN провайдера. И в целом поддержка этого — проблема прошивки, а не стандарта. Я уверен, что на OpenWRT можно соорудить IPv6 VPN, с помощью OpenVPN.

Плюс у нас есть адрес подсети, который привязак к конкретному абоненту/компании. И нет простого способа скрыть эти адреса.

Так в IPv4 точно так же. Вот тебе пример: https://apps.db.ripe.net/db-web-ui/#/query?bflag=true&dflag=false&rfl...

А в целом, во-первых, IPv6 улучшает связанность P2P сетей, во-вторых, он не отменяет I2P, Tor, Freenet и другие анонимные сети.

NAT6 не нужен; более того, даже вреден.

Хотя нет. Это всеравно не совсем то. Да я получу отдельный адрес или даже подсеть. Но из под этого адреса будет выходить одно мое устройство, а не множество разных чужих и мое.

I2P, Tor, Freenet и другие анонимные сети.

Не вариант, весь трафик в тот-же tor не завернешь, плюс он очень медленный.

NAT в IPv6 есть и прекрасно работает. Есть ситуации, когда он нужен.

NAT6:6? Можно пример вендера?

Зависит от типа трафика. Если ты смотришь видео на видеохостингах, то да, Tor неудобный для этого. А если ты независимый журналист, которого могут преследовать власти за публикацию выкрывающих коррупцию и преступлений материалов, то медленные анонимные сети — не такая уж и большая проблема.

В ядре Linux есть IPv6 NAT.

Пример. Для нормальной работы IPv6 в сети Ethernet нужен префикс /64. Провайдер обычно столько и дает. Роутер для LAN использует этот префикс. Но у вас же не только LAN, но еще и Guest. На него глобального префикса не выделено. Поэтому используем приватный из диапазона fd00::/8. Но чтобы гости могли ходить в мир по IPv6, делаем IPv6 NAT. Такая схема реализована, например, в AmpliFi.

Для нормальной работы IPv6 в сети Ethernet нужен префикс /64

4.2

Провайдер обычно столько и дает.

Нормальный провайдер обычно дает ещё и /56 PD для сети за маршрутизатором.

4.2

/64 требуется для нормальной работы SLAAC. Как ты сможешь гарантировать работоспособность устройств, если у тебя /65 или меньше? Ведь никто не обязан поддерживать что-то кроме SLAAC на основе EUI64.

Нормальный провайдер обычно дает ещё и /56 PD для сети за маршрутизатором.

Как правило - только /64. Больше бывает редко.

NAT для ipv6 есть, отлично работает и настраивается точно так же через ip6tables.

Только с DHCP и автоматическим назначением адресов хз, но если прописывать статические адреса вручную (например из сети fc00::) то всё нормально.

Ещё одна особенность - если на интерфейсе локальный адрес (или 6to4 или какой-нибудь miredo), то приоритет ipv6 будет низкий, т.е. если например сайт может и ipv4 и ipv6, то будет открываться ipv4.
Чтобы это исправить, можно что-то прописать в /etc/gai.conf, хотя имхо ненужно

/64 требуется для нормальной работы SLAAC.

Да, но SLAAC не требуется для работы IPv6. Никто не мешает настроить статику.

Как правило - только /64.

Никуда не годный провайдер, если так. Покажи им rfc.

PS. А может ты просто не пробовал получить DHCPv6 PD?

Да, но SLAAC не требуется для работы IPv6. Никто не мешает настроить статику.

Во-первых, даже адрес IPv4 простым людям вводить сложно. А уж адрес IPv6 - это космос.

Во-вторых, в том же Андроиде, например, вообще нет возможности вбить адрес IPv6. Только что проверил на первом попавшемся Самсунге.

SLAAC - это единственное, что работает у всех.

Никуда не годный провайдер, если так.

Они почти все такие. Чудес не бывает. Хорошо, что вообще помаленьку внедряют IPv6. UPD речь идет о клиентах-частниках. На организацию, ясен пень, я получил намного больше.

Покажи им rfc.

Какой?

PS. А может ты просто не пробовал получить DHCPv6 PD?

Пробовал и получать, и раздавать.

Во-первых, даже адрес IPv4 простым людям вводить сложно.

От этого перестаёт работать IPv6?

в том же Андроиде, например

Тот же Андроид, например, вообще не работает в IPv6-only WiFi сетях. Он ни DHCPv6 не умеет, ни адрес DNS получить.

SLAAC - это единственное, что работает у всех.

DHCPv6 тоже работает для большинства. Есть вообще провайдеры, выдающие WAN интерфейсу адрес в /126 или /127. Есть даже использующие на стыке link-local only.

Они почти все такие.

Не везет тебе, если провайдеры вокруг идиоты. Большинство провайдеров в мире нормально выдают DHCPv6-PD. Обычно /56, некоторые — /48 компаниям, а /56 частным клиентам.

Какой?

rfc3177 и дополнения из rfc6177. Также можно посоветовать ознакомиться с RIPE BCOP (Best Current Operational Practices) — ripe-690, если не ошибаюсь.

Пробовал и получать, и раздавать.

Могу посоветовать только менять провайдера или давить текущего, чтобы всё же выдавал клиентским маршрутизаторам /56 для сетей за ними.

Не везет тебе, если провайдеры вокруг идиоты. Большинство провайдеров в мире нормально выдают DHCPv6-PD. Обычно /56, некоторые — /48 компаниям, а /56 частным клиентам.

Большинство именно /64 по моим текущим наблюдениям. Но даже если бы они были меньшинство, все равно нет возможности расчитывать на что-то более щедрое, чем /64. С другой стороны, требуется нормальная работа SLAAC на стороне LAN. Таким образом, потенциально единственный /64 уходит в LAN, а гостевая сетка потенциально остается без глобальных адресов. И если хочется ходить из нее наружу по IPv6, то остается только NAT.

А еще бывает, что IPv6 как бы есть, но PD отсутствует по какой-то причине...

А еще есть British Telecom, раздающий IPv6 по PPPoE...

rfc3177 и дополнения из rfc6177. Также можно посоветовать ознакомиться с RIPE BCOP (Best Current Operational Practices) — ripe-690, если не ошибаюсь.

Спасибо, ознакомлюсь.

Могу посоветовать только менять провайдера или давить текущего, чтобы всё же выдавал клиентским маршрутизаторам /56 для сетей за ними.

Дело в том, что я смотрю на вещи под несколько другим углом, ЕВПОЧЯ. Мой провайдер меня устраивает на 100 процентов. Рекомендовать другим людям менять провайдера я не в праве, да и не у всех в этом мире есть такой выбор.

Ещё одна особенность - если на интерфейсе локальный адрес (или 6to4 или какой-нибудь miredo), то приоритет ipv6 будет низкий, т.е. если например сайт может и ipv4 и ipv6, то будет открываться ipv4. Чтобы это исправить, можно что-то прописать в /etc/gai.conf, хотя имхо ненужно

Вот и правильно, что низкий. Не нужно это исправлять.

Большинство именно /64 по моим текущим наблюдениям.

Абсолютно неоправданное жлобство. Каждый LIR получает на старте /32 и может запросить расширение до /29 одним куском без всяких документов и подтверждений. Сеть /32 — это 16 миллионов /56 префиксов. Выдача до /48 на нос конечному пользователю тоже не требует вообще никаких бумаг и доказательств.

а гостевая сетка потенциально остается без глобальных адресов

Есть, конечно, финт ушами — /64 с WAN развернуть внутрь, оставив на интерфейсе адрес рядом с некст-хопом в одной /127. И оно даже работает.

А еще есть British Telecom, раздающий IPv6 по PPPoE...

У них хотя бы DHCPv6-PD через PPP интерфейс работает, насколько я знаю.

Есть, конечно, финт ушами — /64 с WAN развернуть внутрь, оставив на интерфейсе адрес рядом с некст-хопом в одной /127. И оно даже работает.

Это как?..

Это как?..

Положим, твой провайдер выделяет 2001:0bd8:00ba:b10c::/64 на WAN, и с его стороны адрес 2001:0bd8:00ba:b10c::1. Ты назначаешь себе на WAN 2001:0bd8:00ba:b10c::2/126, а всю сеть 2001:0bd8:00ba:b10c::/64 перекидываешь внутрь. Вместо ::1 и ::2 подставь два рядом стоящих адреса.

Это будет работать, если провайдер добавляет маршрут на 2001:0bd8:00ba:b10c::/64 (routed network), а не устанавливает 2001:0bd8:00ba:b10c::1/64 на сетевой интерфейс со стороны своего маршрутизатора. Но если у вас маршрут, то такой костыль и не нужен, можно сразу назначать всю /64 на локальный интерфейс.

Это будет работать, если провайдер добавляет маршрут

Сеть 2001:0bd8:00ba:b10c::/64 с точки зрения маршрутизатора провайдера direct connected.

можно сразу назначать всю /64 на локальный интерфейс

К сожалению, проблематично назначить одну и ту же /64 на два разных интерфейса.

Если она Direct Connected, то описанный вами способ не должен работать без дополнительных настроек (ndp proxy).

ndp proxy

Конечно, а как иначе?

Если сеть routed, то ndp proxy не нужен. А вы о нём не упомянули в сообщении.

Если сеть routed

О какой маршрутизации ты говоришь, если по условия задачи 2001:0bd8:00ba:b10c::/64 — point-to-point сеть между провайдером и WAN интерфейсом?

А вы о нём не упомянули

«А всю сеть перекидываешь внутрь». Использование NDP proxy в этом случае мне кажется вполне очевидным. Я же не man пишу, а короткое описание «финта ушами».

Странно писать об этой возможности, но не упоминать главного — ndp proxy. Без него-то работать ничего не будет.

Странно писать об этой возможности, но не упоминать главного

Главное здесь — вообще догадаться о возможности «позаимствовать» point-to-point сеть для своих нужд.

Без него-то работать ничего не будет.

Во многих случаях — будет. Как только маршрутизатор провайдера увидит пакет наружу, он изучит MAC (WAN интерфейса) и соотнесет его с IPv6 адресом. Не будет связности снаружи, пока нет попыток доступа изнутри. Только эту проблему решает NDP в данном случае.