+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Запрос на функцию: поддержка IPv6 NAT66

Запрос на функцию: поддержка IPv6 NAT66, RouterOS

Cha0s Guest	#1 0 24.10.2014 12:10:00 Было бы здорово добавить поддержку NAT66 для IPv6 в ROSv7! Спасибо.

Majklik

Guest

18.11.2014 12:36:00

Я не сторонник NAT66, но NPT (RFC6296) в некоторых конфигурациях полезен для малого и среднего бизнеса с многопроводным подключением к Интернету, и ядро Linux это поддерживает. За эту функцию я голосую. Но, пожалуйста, сначала реализуйте политику маршрутизации для IPv6 (без неё многопроводное NPT невозможно) и объявления маршрутизатора с приоритетом выбора маршрутизатора (RFC4191 / разделы 2.1 и 2.2).

R1CH Guest	#3 0 18.11.2014 20:24:00 Если тебе нужно использовать NAT с IPv6, значит, что-то не так.

Cha0s

Guest

18.11.2014 20:51:00

Без обид, но это просто плохой аргумент, и ты прекрасно это знаешь. Если логически подумать, то если ты используешь NAT на IPv4 (а я уверен, что ты так и делаешь), значит, ты что-то делаешь неправильно. Но на самом деле нет правильного или неправильного. NAT — это просто один из многих инструментов. То, что тебе он не нужен или не нравится, не делает его «неправильным». Или то, что так называемые евангелисты IPv6 говорят, что NAT быть не должно, совсем не означает, что для некоторых сетей нет реальных случаев его использования. Я действительно не понимаю, в чём проблема. Если кто-то не хочет использовать NAT (из-за идеологического бреда про IPv6 или потому что нет нужды), то просто не используй его. Но некоторым из нас он нужен, так что хватит уже с этой «пропагандой» про NAT. Если Juniper — компания, которая входит в число лидеров, реально маршрутизирующих весь интернет, — внедряет эту функцию, значит, на то есть веские причины и применения. Я не думаю, что компания, работающая только с корпоративными клиентами, стала бы тратить время на реализацию функции, которую никто не просил. Честно говоря, не понимаю, почему кто-то против функции, которая ему не нужна. Если тебе не нужно — просто не используй. Но не запрещай остальным иметь такую возможность.

docmarius

Guest

19.11.2014 06:52:00

Хорошо. NAT66 — это не выход. Давайте разберёмся... У вас есть приватная сеть, и IPv6-адреса, назначенные вашим устройствам от одного провайдера. Теперь вы хотите добавить второго провайдера для резервирования исходящего IPv6-трафика, и этот провайдер даёт вам ещё одну IPv6-подсеть (возможно, даже динамически назначаемую). Кроме как платить кучу денег за свою собственную IPv6-подсеть и публиковать её через BGP у обоих провайдеров, можете предложить решение, как обеспечить такую избыточность и при этом не менять внутренние IPv6-адреса сети, кроме NAT66?

Второй случай: медленная статическая IPv6-подсеть от первого провайдера. Быстрая динамическая IPv6-подсеть от второго. Хотите принимать входящие подключения через первую и при этом исходящие делать для внутренних машин через вторую... Есть какие-то другие (бюджетные) варианты, кроме NAT66?

Majklik

Guest

19.11.2014 13:31:00

Обе схемы изначально работают с IPv6 без NAT66 и без BGP-пиринга с PI-префиксами. Первый сценарий (активный-резервный мультияхонинг) я использую вместе с роутерами Mikrotik в разных местах уже много лет. Второй (активный-активный мультияхонинг) с Mikrotik сделать нельзя, потому что в ROS нет поддержки policy routing для IPv6.

Второй пример сейчас проще всего реализовать через NPT — Network Prefix Translation (RFC6296) или другие механизмы (настройка выбора адреса источника по умолчанию и так далее). Поддержка NPT была бы полезна в таких случаях в некоторых средах, но прежде всего для этого всё равно не хватает policy routing для IPv6 (и возможности анонса предпочтений роутера) — это основа для активного-активного мультияхонинга в принципе.

docmarius Guest	#7 0 19.11.2014 16:50:00 Хорошо, теперь понял. В принципе, обе ситуации действительно покрываются NPT (я всегда считал это своего рода NAT). Спасибо за разъяснение. Так что +1 за NPT.

Majklik

Guest

20.11.2014 09:22:00

Да, с NPT или любым другим вариантом IPv6 NAT конфигурация выглядит немного проще, чем использовать динамическое перенумерование и прочее… Но, но — вы пробовали использовать какой-нибудь IPv6 NAT в реальной жизни? Я пробовал и очень быстро отказался. Этот NAT ломает прозрачность «от конца до конца», а есть протоколы, которые на неё рассчитывают. Когда я в последний раз тестировал, Linux IPv6 NAT мог работать только с активным FTP. А протоколы вроде IPsec, SIP VoIP, MIP и прочие не могли нормально функционировать через IPv6 NAT. Если покопаться глубже в некоторых редакторских заметках RFC про IPv6 NAT / IPv6 multihoming, там есть рекомендации для реализации IPv6 NAT не делать никаких протокольных помощников, а для разработчиков приложений и протоколов — не усложнять свои продукты и протоколы расширениями для обхода NAT, потому что IPv6 NAT не предназначен как основное решение…

Cha0s

Guest

21.02.2015 17:57:00

Независимо от того, что делают или не делают некоторые приложения/протоколы, иметь в арсенале какую-то форму NAT (по крайней мере NPT) очень полезно. Не все сети одинаковы и не все могут измениться из-за этого произвольного «требования» сквозного соединения. Плюс не все сети подключены к публичному интернету, но может понадобиться быстрый и грязный «шлюз» к нему без кучи изменений IP просто «потому что». Мы все уже два десятилетия пользуемся FTP, SIP и всей этой штукой вместе с NAT. Да, это не идеально и не всегда «правильно», но только потому, что несколько протоколов требуют сквозного подключения для работы, не значит, что NAT становится бесполезным или даже вредным для остальных протоколов. Случаи использования разные. Иначе говоря, допустим, я не использую RIP, потому что предпочитаю OSPF или просто предвзят к RIP. Значит ли это, что Mikrotik (или любой другой производитель) должен отказаться от RIP, потому что я его не люблю или не использую? Конечно, нет. Мне он не нужен, а кому-то другому может быть полезен! Я бы не стал минусовать запросы на добавление функций только потому, что они мне не нужны. Особенно если они не мешают моему способу работы (как я уже сказал, NAT — это просто инструмент, если он вам не нужен — не пользуйтесь).

Matess Guest	#10 0 24.02.2015 12:53:00 Кто-нибудь может объяснить, почему нет NAT с IPv6 (интернет-адреса) на IPv4 (внутреннюю сеть)? Не будем говорить про masquerade, а как насчёт 1:1 NAT?

whinis

Guest

#11

05.01.2016 18:11:00

Я бы тоже поддержал эту идею. У меня в сети много устройств, которым вообще не нужен публичный адрес (локальные медиа-серверы, принтеры), и если мне вдруг понадобится что-то публичное — ничто не мешает назначить ему один из адресов из /64. Возможно, это и не «обязательно», но я не хочу каждый раз менять правила фаервола, когда мой провайдер решит поменять мой текущий /64. Мне хочется контролировать свои назначения (а значит, иметь локальный пул для себя) и разрешать подключение в тот момент, когда я сам решу (NAT).

Zorro

Guest

#12

31.01.2016 16:44:00

Пока что и NAT64, и производные от NAT66 остаются важными и удобными штуками. Также NPT-форки для IPv6, включая перепозиционированные версии от двух крупнейших поставщиков. Но лично мне более симпатичны NAT64 и NAT46 (да, он ТОЖЕ существует ж) — по понятным причинам, всё же ;=) В любом случае — NAT остаётся краеугольным камнем сетей, с IPv6 или без, с TCP/IP или в других формах.

mutinsa Guest	#13 0 05.05.2019 13:39:00 Плюс один.

muetzekoeln Guest	#14 0 05.05.2019 16:58:00 +1 Я пользователь с двумя подключениями для дома, и оба моих провайдера поддерживают IPv6.

bergonz

Guest

#15

08.05.2019 11:46:00

Мультимоухинг IPv6 без BGP почти невозможно сделать «по-IPv6», то есть с двумя анонсируемыми префиксами в одной и той же локальной сети от двух роутеров двух разных провайдеров. Большинство используют NAT66, чтобы получить предсказуемое поведение в случае выхода одного из них из строя. Я использую это с iptables, которое уже много лет входит в состав ядра Linux. Можно добавить это в список преимуществ обновлённого ядра. Мне кажется, что stateless NPTv6 тоже полезен (он решает описанную выше задачу), но у меня пока нет рабочего внедрения. Я уже давно использую ND proxy на устройстве OpenWRT, которое сейчас пытаюсь заменить на mikrotik с bridgе firewall + «use-ip-firewall», то есть ND bridge со stateful IPv6 firewall (один и тот же /64 префикс в двух интерфейсах). Занимаюсь этим в свободное время, но как только закончу, обязательно дам знать.

pe1chl Guest	#16 0 08.05.2019 12:06:00 Я спросил на недавнем MUM, будут ли расширения для IPv6 (привёл в пример только политическое маршрутизация, ведь без неё использование NAT66 тоже не имеет смысла), и, к сожалению, ответ был, что MikroTik не видит большого спроса на IPv6, и новых разработок по нему стоит ждать не раньше RouterOS версии 7. (и, конечно, мы все про это прекрасно знаем…) Жаль, потому что на самом деле ядро Linux в версии 6, наверное, уже способно сделать всё необходимое для хотя бы минимальной поддержки двойного uplink IPv6 без BGP-маршрутизации — просто для балансировки нагрузки и резервирования.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры