Почему IPv6 всё ещё не взлетел. Практические выводы пользователя IPv6 и опрос

Как часто говорят "лучшее враг хорошего" — но мы всё равно верим в лучшее и иногда встаем по несколько раз на одни и те же грабли. А ведь всё так хорошо начиналось, когда пару лет назад в одном мануале к новой версии сервера приложений, я обнаружил очень настойчивые (всё будет работать быстрее и лучше) рекомендации по внедрению IPv6 для корректной и эффективной работы системы на новом протоколе. А так как я отношусь к мануалам с уважением, то сказано — сделано, и сеть настроена с новым протоколом и установленным сервером приложений — действительно всё работало быстро и корректно. Но потом всё пошло не так...


image

Прошло пару недель и так как в той организации у многих был выключен протокол V6, то и глюков почти не было. Но потом, коллега что-то настраивал в роутере и в бухгалтерии всё перестало работать. И так как было непонятно, что не так, то настроил роутер (микротик) заново, но без IPv6. Все прекрасно заработало. Всё списал на криворукость коллеги и продолжал верить в светлое будущее IPv6 и поэтому настроил его для своего сайта на хостинге и успешно проверив, оставил его там работать.


Прошло полгода и в другой небольшой организации нужно было настроить пару серверов и сеть. И так как там в одной системе тоже были настоятельные рекомендации ускориться по IPv6, то и решил сделать всё "как книжка пишет". Но не прошло и дня после настройки и тестов, как выяснилось, что достаточно много программ, и приложений не просто не поддерживают IPv6, а безуспешно пытаются работать одновременно на двух протоколах и первой такой ласточкой стал Skype for business. И неудивительно критическое требования руководства — незамедлительно восстановить работу меcсенджера, и вот скрепя сердце отключаю "путь к прогрессу" — IPv6. И после успешных проверок работы свежеустановленной системы и скайпа по старому IPv4 — замечаю, что скорость не пострадала. А сетевые ресурсы и сайты, которые доступны только на IPv4, открываются без полусекундной задержки (с включенным IPv6). В поддержке MS по бизнес скайпу, писалось что включена экспериментальная поддержка IPv6 и нормальная работа не гарантировалась. Ещё рано, потерпи ещё немного IPv6 время не пришло — подумал я. Прошло пару лет.


Заметил, что после настройки DMARC и доменных записей почты для сайта, иногда фильтр срабатывал и в то же время было пару случаев, что клиент оформил заказ, а уведомление менеджеру на почту не пришло. Тут я и вспомнил про включение для сайта IPv6. Чтобы подтвердить версию с глюком V6, настраиваю у себя на роутере (mikrotik) через брокер netassist, отключаю IPv4, проверяю — пинг по доменному имени ua-opt.com идет, значит и DNS и маршрутизация работает. Иду в хром и на сайт — пишет внизу "защищаем соединение" и висит. Иду на гугл все гуд, и так 2-3 из 10 сайтов работает, остальные — часть вообще не работает по IPv6, часть сайтов показывает также как и на моем "защищаем соединение" и висит. Но что меня убило — также и сайт хостинга "защищает соединение" и не грузится. Значит проблема серьезней, чем я думал… Но вера в IPv6 не утрачена, делаю вывод — "ну и криворукий же я" и 5 раз перенастраиваю протокол по разным мануалам, меняю брокер на Hurricane Electric, пробую другие браузеры (инкогнито и прочее), даже перегружаюсь. И опять тот же результат. Но стоп! Ведь днс работает, ping идет значит клиент — всё гуд — глюк на сервере. Проверяем ДНС записи на хостинге всё гуд — IPv6 адрес прописан правильно. Да и сам сайт хостинга по IPv6 не работает, хотя пингуется. Значит SSL! И ведь точно с момента как всё работало на V6, я перевел сайт на HTTPS. Читаю в доке Let's Encrypt поддержка v6 есть, и на хостинге в настройках доменных записей — всё как нужно прописано. Ищу дальше и нахожу возможный источник проблемы — в настройках Nginx возможно не настроено или настроено неправильно несколько параметров связанных прослушиванием порта 443(ssl). Причем в числе возможных решений — есть одно 100% работающее — выключить IPv6 на сайте. Выключил — полегчало, хотя мысль о тысячах пользователях у которых был включен v6 и сайт висел, прочно засела громадным камнем в огород "злополучного" протокола. Пришло время всё осмыслить… и понять что тут не так.


Для начала возьмем скайп — если на клиенте включен IP v6 и v4, то работать он будет по умолчанию по v6, далее к серверу он подсоединился по v6 — то как ему подключиться к клиенту v4? Допустим сервер MS допилили и он интеллектуально видит, что второй юзер только с v4, он может послать команду клиенту c v6 и v4 общаться со вторым по v4. Ну, а если у первого только v6? В логике возможной беспроблемной реализации работы v6 пока тупик… Но корень проблемы в работе приложений уже ясен — ведь это технически непростая задача — состыковать в клиенте два разных протокола, но ведь туннельные брокеры справляются, так что в теории проблема решаема. Только вот решать её никто не берется.


Вторая проблема с сайтом и SSL — это лишь верхушка айсберга проблем связанных с разными настройками комбинаций технологий используемых для соединения, шифрования и передачи данных на хостингах и сервис провайдерах. И большинство конечных пользователей решает эти проблемы для себя путем IPv6=OFF, как самым быстрым и оптимальным решением.


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


  1. Отсутсвие обратной совместимости IPv4. Это первая и основная причина — IP v6 кардинально отличается от v4, поэтому много наработок для v4 нужно полностью переосмысливать и переделывать. Для примера можно отметить проблемы с v6 в мобильных сетях при переключениях между базовыми точками. Также это выливается в сложность (а часто невозможность) состыковки устройств или клиентов с разными версиями протокола. Так революционный путь V6 вместо эволюционного, сделал технически крайне сложным переход для разработчиков программ, устройств, систем и технологий, а также провайдеров, хостингов, сетевых операторов. Во многих случаях конечной точкой внедрения сейчас является IPv6=Off.

    image
  2. Проблемы с внедрением v6 у сервис-провайдеров и мобильных операторов — для полноценной работы по IPv6 в масштабах страны необходима поддержка протокола на всех элементах, участвующих в пропуске трафика, включая, например, клиентское оборудование – в этом сложность его внедрения. Также много проблем и у наземных провайдеров и операторов. Скорость внедрения IP v6 критически ниже скорости исчерпания IP v4 адресов.
  3. Проблемы с внедрением даже для локальных систем и конечных пользователей. Для последних — пускай и незначительная, но иногда весомая часть сайтов становится недоступна (виноваты хостинги или владельцы сайтов, но тем не менее), не работают (или глючат) некоторые критически важные приложения, появляются задержки при переключении между протоколами в браузерах или клиентских программах

Получается что куда ни пни всюду ворох проблем, а ведь изначально нужно было только решить проблему с адресным ресурсом! А теперь "Мышка за Машку, Машка за Жучку, Жучка за внучку, внучка за бабку, бабка за дедку, дедка за IPv6: тянут-потянут — и выключили его на… время!

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

Удалось ли вам внедрить у себя протокол IPv6?

  • 13,0%Удалось — все работает без проблем, забыл про IPv470
  • 6,3%Удалось, были проблемы — но решили, или (и) отказались от некоторого функционала для внедрения IPv634
  • 22,3%Пробовали — не удалось, отказались от внедрения120
  • 52,8%Не пробовали, итак всё устраивает284
  • 5,6%Планируем внедрять, IPv6 лучший протокол в мире!30
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 277

    +8

    Такими темпами он устареет просто напросто.

      +2

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

        +3
        Хм, а как сейчас в этих случаях работает IPv4 тогда? Он лучше чем v6 в этом конкретном случае?
          +2
          А станции разрабатывались под ipv4 ;)
          +8
          Странно слышать, с базовыми станциями вроде особых проблем нет. И IPv4 и IPv6 одинаково заворачиваются в GTP и транслируется к шлюзу доступа, которому совершенно безразлична конкретная базовая станция внутри региона. В текущей схеме (2G/3G/4G) каждый такой шлюз работает со своим пулом адресов, и переход между шлюзами подразумевает смену внешнего IP. Поэтому IPv6 именно для мобильных пользователей вроде ничего, по сравнению с IPv4 не поменял.
            0

            Спасибо за грамотный ответ, выходит ту информацию, что читал уже устарела.

              0
              Вроде разрабатывается Mobile IPv6, а, значит, с обычным IP все-таки есть какие-то проблемы в мобильных сетях
                0
                Mobile IP есть и для IPv4, его идея в сохранении внешнего адреса (v4 или v6) выделенного устройству. Предполагается, что телефон (девайс) сохраняет его выделенные ему адрес при попадании в роуминг другого оператора или перемещаясь на другой конец земли или меняя тип подключения.
                С одной стороны это даёт возможность иметь фиксированный внешний адрес, что особенно актуально для IPv6 и VoIP, можно менять тип доступа в сеть, переключать между 3G и WiFi например — а всё соединения остаются работать. С другой стороны, для этого трафик перенаправляется всё на тот же шлюз доступа. Т.е., условно, вы например абонент московского сотового оператора приехали во Владивосток и хотите зайти на городской сайт, хостящейся во Владивостоке же. Без Mobile IP шлюз доступа где-то на дальнем востоке получит трафик от вас и завернет его в интернет, и в идеале, всё будет циркулировать внутри дальневосточного региона, с минимальным пингом. Благодаря Mobile IP, ваш трафик будет ретранслирован в Москву, к вашему домашнему шлюзу доступа в сеть и уже от туда вернётся во Владивосток, увеличивая пинг, но сохраняя московский IP.
                По сути Mobile IPv6 создан, чтобы снять с разработчиков приложений головную боль по переподключению при смене внешнего адреса, но это не связано с какими-то прямо принципиальными отличиями применения IPv6 от IPv4 в мобильных сетях.
                  +1

                  Вы будете удивлены, но и сейчас мобильный трафик бежит по длинному пути через домашний регион (прям как вы описали в схеме Mobile IP).
                  Пример. Екатеринбургская симка Мегафона находясь в Питере имеет пинги до серверов в СПБ 100+мс. По traceroute видно как сначала трафик долго бежит по внутренней сети Мегафона 10.x.x.x, потом выныривает в public internet в Мегафон-Урал => затем Мегафон-Поволжье => Москва => СПб.
                  Представляю что творится с дальневосточной симкой в Питере...

                    0
                    Так было уже во времена 2G. Для горячего биллинга, чтобы абоненты не загонялись в глубокий минус. Можно выпускать и через гостевого оператора, но тогда сложности с межоператорскими рассчётами и абоненты в минусах. Для этого и существует специальная межоператорская сеть GRX/IPX.
                      0
                      Наверное пример просто не удачный. Mobile IP в добавок к тому что вы описываете, предполагает такое же поведение и при роуминге в сети другого оператора, который отправит ваш трафик в ваш домашний регион. И при переключении просто в другую сеть, например к домашнему WiFi, когда трафик из него улетит не в живую в сеть, а опять же сначала в сеть оператора. Это опять же сильно утрированно.
                      А то что вы описали, связанно всё же не с особенностями 2G/3G/4G, а с работой конкретного оператора. Может им было так проще сделать для горячего биллинга, как выше написал wlr398. Может это специфика их пиринга с другими операторами. Но это не особенность сетей сотовой связи, связанная с их архитектурой или какими-то требованиями/спецификациями. Это то, то как конкретный оператор настроил свои сети.
          +7
          В протокол было вложено слишком много разного, однако что-то откатили ещё до практического взлёта, что-то поменяли уже в процессе. В целом ИМХО на данный момент из потребного от IPv6 остаётся расширение адресации, с остальным большие проблемы. ОЧЕНЬ большие.

          Мой личный опыт работы с протоколом — много страданий. Из 3-х имеющихся серверов в инете IPv6 вырублен нафиг на 2 (привет российским лоукостерам, пытаться от них добиться починки связности по IPv6 — легче вырубить и забыть). Кроме того, у меня вызывают недоумение следующие ужасы:
          1. Настройка firewall-а для локалки чудовищна. Чтобы оно заработало приходится открывать ICMP на широкие диапазоны серой сети и локальную подсеть для белой. Если сидишь хостинге в одном L2 сегменте с группой фиг пойми кого — это страшно.
          2. Hetzner на убогую виртуалку выдаёт сеть /64. Мне на этой виртуалке эти адреса в таком количестве зачем нужны? Или «сверху» поставлен план утилизировать адреса за 10 лет, стахановскими темпами? Так их на миллионы рассчитанных лет не хватит. Причём народ в статьях дико обижается когда на эти убогие виртуалки не выдаётся такой сети. Нет, я понимаю от провайдера клиенту с барского плеча, но виртуалке на кой?!111
          3. В своё время прочитал божественный курс лекций по IPv4 (на данный момент институт, на сайте которого лежал материал, его убрал, ну да бог им судья). Не видел исчерпывающего описания IPv6. Вот прям сейчас это набор RFC, которые друг-друга корректируют, и бездонная прорва статеек, по теме включить протокол, накатить адрес и дальше разбираться по ходу дела. Лично мне данный протокол всё ещё не понятен и является скорее темным мешком неожиданных неприятностей. Для чего-то, что на хайпе столь продолжительное время это уже даже не «непростительно», это блин диагноз…
            0
            В локальных сетях главная проблема это то, что при настройке согласно идеям IPv6 получаем у всех устройств «белые IP» и соответственно проблемы с безопасностью. Вроде бы и всё так, как задумано, но…
            Есть и плюс — с IPv6 ping меньше.
              0
              Ну да, вместо NAT вам придётся на шлюзе ещё и фаервол настроить для фильтрации трафика. Впрочем, NAT — не панацея…
                +4
                Если проблемы с безопасностью не решаются локальным файрволлом, то версия протокола тут ни при чём.
                  +1
                  Вы конечно правы. Однако, всё решает цена/качество. Вот сейчас по этому параметру для «дефолтной винды домохозяйки» выиграл принцип — «комп за NATом роутера, на компе дефолтовый антивирус виндвоз». Если снести NAT — это уполовнит и так не очень эффективную защиту.
                    +6

                    Рутер, который способен делать stateful connection tracking (а NAT без этого не работает), совершенно спокойно потянет совершенно тупой практически не-stateful файрволл для IPv6 вида "наружу пропускаем все, а внутрь — только пакеты с установленным флажком установленного соединения.


                    Так что там, где у IPv4-го маршрутизатора по умолчанию NAT без настроек, у IPv6 по умолчанию односторонний файрволл тоже без настроек.


                    Эквивалентом прокидывания порта внутрь (как с NAT делать иногда надо) будет просто открытие порта на вход.
                    Интерфейс с точки зрения пользователя может быть совершенно идентичным.

                      0
                      Да. Такой вариант рабочий! Осталось только подождать. Сколько ждать? Роутеры за домохозяйским лицом( с WiFi-паролем обязательным хотя бы ) появились при крайней необходимости за ~10 лет. Без крайней необходимости, то о чём вы говорите появится не скоро. Кто в принципе, кроме рынка, может обязать производителей сделать по-человечески?
                        +2
                        Кто в принципе, кроме рынка, может обязать производителей сделать по-человечески?

                        Производители, в общем, в свое время практически подтянулись. Но выяснилось, что возиться с IPv6 не хотят операторы. И производители домашних железок на это дело плюнули.

                          +1
                          Сколько ждать? Роутеры за домохозяйским лицом( с WiFi-паролем обязательным хотя бы ) появились при крайней необходимости за ~10 лет.

                          Домохозяйские маршрутизаторы уже себя так и ведут.

                        –2

                        Да и для "администраторов домашней сети" типа меня NAT гораздо удобнее. В квартире уже, наверное, больше десятка девайсов минимум на 4-х ОС и на всех дефолтные для этой ОС настройки безопасности. Я вот сейчас даже не знаю, есть ли и включены ли по дефолту локальные файерволы на Windows 7 и 10, Android от 7 до 10, какая-то iOS несвежая, ну и Ubuntu 18.04. Разбираться со всем этим превентивно нет ни малейшего желания, только в процессе решения конкретных задач типа поднять на ноутбуке жены nginx+php-fpm так, чтоб они были доступны в домашней сети и только. Тогда может оказаться, что 80-й порт закрыт у неё вообще для внешнего доступа и надо открыть его для всех с точки зрения локального файервола, а по факту для домашней сети.

                          0
                          А вот надо бы. Достаточно привнесенного в локалку постороннего зараженного девайса (например, от пришедшего в гости друга или коллеги, прибывшего в команировку). Именно так происходила эпидемия WannaCry в свое время.
                            –2

                            Я не специалист по подобной безопасности и становиться им особо не хочу.

                              +2
                              Ваш ответ звучит как «я не специалист по ЗПП и становиться им особо не хочу, поэтому во всех этих ваших кондомах разбираться не буду, да и пользоваться тоже». Может все-таки стоит?
                                0

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

                            0
                            NAT гораздо удобнее

                            NAT — это тот самый костыль, который обязан существовать в v4, потому что адресов на всех на самом деле не хватает уже сейчас. «Удобнее» он только потому что все роутеры настроены на его использование по умолчанию и не надо с этим возиться руками. К тому же, NAT != firewall, см. например habr.com/ru/post/134638. И именно правильно настроенный файрволл от этого защищает. А настраивать FW на каждой машине внутри сети не нужно: достаточно правильно настроенного FW на роутере.
                              0

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

                                0
                                Чтобы не светить напрямую, и нужен файрволл. Более того, я сильно подозреваю, что в большинстве поддерживающих IPv6 домашних роутеров это сделано по умолчанию, также как и NAT для IPv4.
                                домен отдельный поднимать и поддерживать задолбаешься

                                А как решалась бы эта же задача в IPv4 с NAT, когда провайдер выдает не подсеть, а всего один адрес? В самом типовом случае пробросом портов. В IPv6 делаешь ровно то же самое, и всё схлопывается в один адрес, который вполне можно «поднять и поддерживать», а через DynDNS это делается вообще автоматически.
                                  +2
                                  Как бы, и возникает возврат к вопросу: «И зачем домашнему пользователю IPv6»? Что так IPv4 без NAT жизни нет, что этак IPv6 без NAT жизнь весьма и весьма тяжела, вплоть до полной невозможности. Тем более что и в дороге, на пути поддержки IPv6, сервиса никто не обещал ;)
                                    0
                                    Никакого возврата не возникает, так как «домашнему пользователю» вообще всё равно, что у него там, IPv4 или IPv6 или что-то ещё, если оно «просто работает».
                                    IPv6 без NAT жизнь весьма и весьма тяжела

                                    Ну, во-первых, это уже не тот NAT, который подразумевается, когда мы говорим о домашних роутерах и IPv4. Тот называется masquerade и в IPv4 необходим, чтобы выжить, в IPv6 же достаточно простого DNAT, проброса портов. А во-вторых, при желании можно на домашнем сервачке завести свой DynDNS клиент, сделав ему свое имя, и тогда даже никакой DNAT не нужен.
                                      +1
                                      DNAT? Нет, ну если поставщик поддерживает DHCPv6-PD, Интернет более устойчив, чем даже питание 230В, и не требуется резервное подключение, то ж может быть, может быть, и DNAT+DynDNS будут ещё туда-сюда.

                                      Но если, скажем, взять Интернет на даче от МТС, в котором при каждом переподключении модема изменяется префикс сети IPv6, то нужен же нормальный, полноценный NAT.
                                        0
                                        Всё же до конца неясно, почему нужен именно маскарадинг и где не хватает DNAT? В чем именно заключается проблема?
                                          0
                                          Очень просто — но не в один шаг, а в два. Если защитные меры с временными адресами SLAAC не работают (потому что их тупо недодумали) — то будет работать не хуже тот механизм, который это вообще не использует. И тут классический NAT с маскарадингом резко получает преимущества — 1) вылизан десятилетиями, как на раутерах, так и в приложениях, 2) скрывает структуру всей сети, не давая утечки, например, как хосты (с характерной активностью) сгруппированы по внутренним подсетям.
                                            0
                                            Но что мешает «скрыть структуру сети» без использования маскарадинга? Опять же, скрыть от кого/чего? MITM на стороне провайдера что ли, который следит за всем проходящим трафиком? И почему защитные меры «не работают»? Предлагаю для начала определиться, от какого сценария вы пытаетесь защищаться.
                                              0
                                              > MITM на стороне провайдера что ли, который следит за всем проходящим трафиком?

                                              Не обязательно на стороне провайдера, хотя и это следует предполагать («искусствовед в штатском» с соответствующими корочками); может быть и со стороны популярного сайта.

                                              Сценарии, например, следующие:
                                              1. Если разрешены входящие согласно IP: видим коннект с любого IP и тут же его тестируем на все дыры, какие знаем из возможно незакрытых.
                                              2. Определяем по характеру запросов с разных адресов, группируя по блокам /64, каким категориям сетей они принадлежат. Временные адреса по SLAAC от этого не спасут, они выдаются в той же сети. Дальше по характеру запросов определяем наиболее вероятное использование (типа: продажники, бухгалтерия, безопасники и т.п.), определяя, на какую из них лучше нацелить усилия. При APT это окупается результатом атаки.
                                                0
                                                Если хосты не закрыты файрволлом, то ССЗБ. Если закрыты, но какие-то порты открыты и их можно атаковать — чем это отличается от port forwarding?
                                                  0
                                                  Я писал тут. Пожалуйста, посмотрите три варианта и скажите, какое решение вы из них предлагаете и как оно будет работать с задачей принять входящие соединения там, где они нужны, и одновременно не принимать там, где не нужны.
                                                    0
                                                    Никакое. FW может фильтровать все прилетающие из интернета пакеты, кроме «DST IP такой-то, порт такой-то» и established,related. Такой вариант почему-то не рассмотрен.
                                                    В той ветке, кстати, так и не был получен ответ на вопрос, чем тут может помочь NAT.
                                                      0
                                                      > В той ветке, кстати, так и не был получен ответ на вопрос, чем тут может помочь NAT.

                                                      Я ответил: тем, что скрывает внутреннюю структуру всей сети и тем самым значительно усложняет атаки извне.

                                                      > FW может фильтровать все прилетающие из интернета пакеты, кроме «DST IP такой-то, порт такой-то» и established,related. Такой вариант почему-то не рассмотрен.

                                                      Established может возникнуть только для исходящих соединений. Related — для тех, что уже явно разрешены файрволлом на основании данных других соединений. Кроме ICMP, это означает логику анализа проходящих пакетов. То есть вы выступаете за вариант 3, но при этом говорите про «никакой».

                                                      Вы уж определитесь, крестик или трусы?
                                                        0
                                                        >Я ответил: тем, что скрывает внутреннюю структуру всей сети
                                                        Ну, допустим
                                                        >и тем самым значительно усложняет атаки извне
                                                        Это каким же образом? Теперь у атакующего есть один IP адрес, на котором висят несколько открытых портов. Перебор портов на одном адресе — гораздо более простая задача, чем поиск откликающихся на SYN адресов в /64 подсети.
                                                        >То есть вы выступаете за вариант 3, но при этом говорите про «никакой»
                                                        Окей, пусть будет вариант 3, видимо я не смог его распарсить. На самом деле тут во многих случаях никакого анализа пакетов не требуется, если правильно настроить сервер (например, у FTP и торрентов можно ограничить диапазон используемых портов и в FW открыть их все сразу), но допустим. Так всё же, чем тут NAT-то вам может помочь? Наоборот, он как раз всё усложняет, как вы собираетесь NAT-ить тот же FTP? С NAT-ом вам нужно помимо FW ещё правильно форвардинг порта настроить.
                                                          0
                                                          > Это каким же образом? Теперь у атакующего есть один IP адрес, на котором висят несколько открытых портов. Перебор портов на одном адресе — гораздо более простая задача, чем поиск откликающихся на SYN адресов в /64 подсети.

                                                          1. Вы очевидно не в курсе работы NAT. Те из них, что «симметричные», откликаются на входящие на конкретный внешний адрес только для установленного для него ремотного. Остальные могут туда же стучаться и будут тупо проигнорированы.

                                                          2. Что ещё важнее — даже если NAT конусовый, кто будет _с_ внутренних критичных портов стуаться наружу? Они только для входящих.

                                                          3. NATу можно дать много внешних IP, хоть те же 2**64.

                                                          > например, у FTP и торрентов можно ограничить диапазон используемых портов и в FW открыть их все сразу

                                                          Это всё ручные действия.

                                                          > С NAT-ом вам нужно помимо FW ещё правильно форвардинг порта настроить.

                                                          1. STUN, TURN.
                                                          2. PCP. Только не надо рассказывать, что его можно и к IPv6 прикрутить — на практике-то апологеты «простой файрволл всё решает» утверждают, что ничего такого не нужно, и без подобных мер всё работает…
                                                            0
                                                            Я честно попытался понять, что вы хотите до меня донести, и не смог.
                                                            >Вы очевидно не в курсе работы NAT
                                                            Допустим, просвещайте
                                                            >Те из них, что «симметричные», откликаются на входящие на конкретный внешний адрес только для установленного для него ремотного
                                                            И много вы знаете квартир, в которых работает симметричный NAT?
                                                            >даже если NAT конусовый, кто будет _с_ внутренних критичных портов стуаться наружу
                                                            Эту часть я вообще не понял, кто, зачем, куда стучится, какую проблему мы решаем — ничего непонятно.
                                                            >Это всё ручные действия.
                                                            Ну и что? Чем это плохо, если речь о домашних пользоателях и одном-двух сервисах, которые хочется открыть наружу?
                                                            >STUN, TURN.
                                                            Круто: сделаем себе NAT, огребём проблем и будем их героически решать
                                                            >PCP
                                                            Требуется поддержка со стороны софта, насколько я понимаю.

                                                            Предлагаю сделать проще: опишите ещё раз, пожалуйста, сценарий, в котором возникает проблема, саму эту проблему, как именно её решает маскарадинг (или какой там вид NAT считается «полноценным») и почему её нельзя решить без него в IPv6. Наверняка такие сценарии действительно существуют, только вот сомневаюсь, что они относятся к домашним сетям.
                                                0
                                                Опять же, скрыть от кого/чего?

                                                От себя, любимого. Чтобы при подсоединении к своей сети снаружи не надо было держать в голове "а файлопомойку я на другой ip вчера перенёс".

                                                  0
                                                  DNAT для этого вполне достаточно, разве нет?
                                              0
                                              Например, следующие сценарии:
                                              1. Приезжаю на дачу или возвращаюсь с дачи после длительного отсутствия, включаю питание, и, если Интернет именно в этот момент не доступен, то дачная/домашняя сеть будет тормозить, как при включении, так и после того, когда по DHCPv6-PD получит новый префикс;
                                              2. Внезапно Теле2 предложил более выгодный тариф, чем МТС. Или более изощрённый вариант, в подъезде отключили электричество, проводной домашний Интернет тоже того-с, домашнее хозяйство на ИБП переходит на сотовую связь, но там выдают новый префикс — тормоза.


                                              Косвенно, не даром же, тот же МТС по сию пору DHCPv6-PD не поддерживает. Кому надо, тому всё равно нужен полноценный NAT (или AS), кому не надо, тому и случайный префикс /64 при каждом соединении сойдёт.
                                                0
                                                >если Интернет именно в этот момент не доступен, то дачная/домашняя сеть будет тормозить
                                                Почему? Как от этого поможет «полноценный NAT»?
                                                >выдают новый префикс — тормоза
                                                Опять же, почему?

                                                Для внутренней сети можно использовать адреса ULA, они будут более-менее статические и работать будут всегда, тормозить ничего не будет. Для выхода в интернет каждое устройство будет использовать tempaddr, а в качестве постоянного глобального адреса (на случай необходимости организации доступа извне без форвардинга) — адрес из выданной провайдером через DHCPv6-PD подсети. Этот адрес будет изменяться только при смене провайдера, так что для устройств, недоступных извне, смена провайдера будет прозрачна, а для остальных хватит того же DynDNS либо проброса портов.
                                                  +1
                                                  Для внутренней сети можно использовать адреса ULA, они будут более-менее статические и работать будут всегда
                                                  Так и да, здесь консенсус.
                                                  … тормозить ничего не будет. Для выхода в интернет каждое устройство будет использовать tempaddr...
                                                  Собственно, а зачем этим устройством выходить в Интернет под внешними адресами «tempaddr»? Если можно выходить с ULA адресов и NAT/прокси/МЭ?

                                                  Насчёт тормозов, если внешние адреса появляются на устройствах и виртуальных машинах, то они попадают в zeroconf/avahi и SMB, скажем, тот же `ssh -6 user@host.local' может случайно использовать внешний адрес.

                                                  Ну и естественно, если они просыпаются, а префикс внешних адресов сменился, то как-бы тормоза.
                                                  … адрес из выданной провайдером через DHCPv6-PD подсети. Этот адрес будет изменяться только при смене провайдера...
                                                  Не каждый провайдер IPv6 поддерживает DHCPv6-PD. Кроме того, даже при поддержке DHCPv6-PD, провайдер не гарантирует постоянства префикса, особенно при длительных перерывах связи.

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

                                                  Кроме того для узлов, с доступом извне, наличие внешних адресов нежелательно по тем же причинам, что и для внутренних узлов.
                                                  для остальных хватит того же DynDNS либо проброса портов
                                                  Почему «либо», всё равно ж нужен какой ни какой межсетевой экран, а проброс с помощью NAT/прокси/МЭ это надёжно.

                                                  Поэтому, на мой взгляд, да, при наличии DHCPv6-PD и очень надёжного поставщика IPv6, хотя и можно обойтись без нормального NAT, но это недальновидно.

                                                  P.S.
                                                  По большому счёту, DHCPv6-PD это ж для конфигурации внутренних сетей, зачем его использовать не по назначению? А для полноценной поддержки внешних адресов следует получить свою автономную систему IPv6 с блоком адресов принадлежащих непосредственно Вам.
                                                    0
                                                    Суть-то в чем: маскарадинг становится не нужен. Тот NAT, который порты пробрасывает, никуда не девается, он по-прежнему работает точно так же как и раньше, это ж тупо замена одних байтиков в пакете на другие.
                                                    если внешние адреса появляются на устройствах и виртуальных машинах, то они попадают в zeroconf/avahi и SMB, скажем, тот же `ssh -6 user@host.local' может случайно использовать внешний адрес

                                                    Честно скажу, тут я не особо в курсе, как эти штуки работают под капотом, но сначала попробовал бы решить именно эту проблему — попадание «белых» адресов в zeroconf/avahi. По моей идее, в локалке они должны ходить друг к другу только по ULA адресам. Если всё внутри работает по ULA, остальных проблем с доступом между хостами и тормозами не должно быть.
                                                    Почему «либо», всё равно ж нужен какой ни какой межсетевой экран, а проброс с помощью NAT/прокси/МЭ это надёжно.

                                                    Имелось в виду, что для доступа к fileserver.local:443 снаружи можно пойти двумя путями: поднять на нём отдельный DynDNS клиент с отдельной записью fileserver.blablabla, либо пробрасывать в него порт с router.local. FW при этом никуда не девается, просто разные правила при этом нужно добавлять.
                                                    DHCPv6-PD это ж для конфигурации внутренних сетей

                                                    Ну да, но всегда найдется кто-то, кто захочет сделать всё по-своему.
                                                      0
                                                      При наличии нескольких адресов будет выбран тот где префикс «ближе».
                                                      При наличии нескольких адресов с одинаковой длинной префикса будет выбран адрес из префикса с наибольшим приоритетом, сначала ULA, потом остальные. Этот порядок можно переопределять в линуксе в /etc/gai.conf
                                        0

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

                                          0

                                          зачем?

                                            0

                                            Экономия на администрировании внешнего домена. Сокрытие информации о внутреннем устройстве сети для возможности её прозрачного переконфигурирования.

                                            0

                                            Насколько я понимаю, одна из идей IPv6 — что, наоборот, каждый сервис можно не только на отдельный порт повесить, но и на свой отдельный адрес. Даже если физически они на одной машине. Так что желание "чтобы выглядело как один сервер" не очень понятно.

                                              0

                                              Можно-то можно, но непонятно зачем. Для домашней сети для меня это выглядит как "дорвались до бесплатного", типа адресов теперь много, жалко не использовать, раз оплачено.


                                              P.S. Ну и в целом зачем мне следовать идеям, если никакой ценности они для меня не несут? Вот больше ip белых статических адресов для классических сценариев использования — понятная для меня ценность, на халяву я бы два взял для каждого своего проводного провайдера, то есть четыре, не два как сейчас и только условно статических.


                                              Высасывать же из пальца новые сценарии использования не хочется.

                                                +1
                                                Вообще то идея в другом. Вот висит у Вас Web-сервер на одном адресе, ssh на втором, VPN на третьем. У хакеров практически нет шансов найти нужный им адрес. Только если они его получат через MITM, кеш DNS или сканируя порты каждого из 264 адресов. То есть шанс атаки чего то кроме публичного сайта стремится к нулю. Это очень сильно усложняет удалённый взлом.
                                                  0

                                                  Хм… Сокрытие внутреннего устройства сети путём создания фиктивных хостов. Мысль интересная. Спасибо.


                                                  Но как подумаешь как это всё админить, да переключать… Вот бы какой-нибудь механизм динамического создания IP на уровне ОС, когда приложение пытается открыть порт на несуществующем. Такого ещё не придумали?

                                                    0
                                                    В принципе контейнеры берут себе по отдельному адресу, но их настройка при наличии лишь одной /64, не так уж и проста.
                                                    0
                                                    > Вот висит у Вас Web-сервер на одном адресе, ssh на втором, VPN на третьем. У хакеров практически нет шансов найти нужный им адрес.

                                                    Он есть в 99.9% случаев, потому что авторы подобных размещений будут такие три адреса выбирать из первой, в лучшем случае, тысячи адресов, или чего-то столь же очевидного типа ::1122:3344.

                                                    2**64 адресов тут… ну разве что вы в записную книжку запишете (окажетесь одним из тысячи, который на это пойдёт — даже copy-paste из гуглодоков это большинству тяжело) или в персональный DNS (который хакеры найдут, рано или поздно).
                                                      0
                                                      Если давать им имена вроде ssh.example.com то конечно найдут. А ssh-s25.username.example.net, найти будет гораздо сложнее. И в общем то совершенно невозможно будет узнать, принадлежат ли они одной системе. А если немного заморочится и получить адреса из другого диапазона, то и принадлежность адреса конкретной сети. Профессиональных хакеров не интересуют взлом случайной лампочки, а боты и скрипкидисы точно не найдут альтернативный домен.
                                                      ::1122:3344.
                                                      Если человек хочет превратить адрес в секретный ключ, то очевидно не станет так делать.
                                                0
                                                Ок, и в чем именно возникает проблема?
                                                  0

                                                  Как по мне, то когда сервисы на нескольких разных адресах внутри сети выглядят снаружи как несколько сервисов на разных сетях, то это NAT. А все говорят, что в ipv6 NAT то ли нельзя использовать, то ли нельзя никому говорить, что используешь.

                                                    0
                                                    Тут есть некая путаница. Тот NAT, о котором вы говорите, это DNAT — destination NAT, и он работает очень просто: сравниваются IP и порт в пакете с указанными в правилах, если есть совпадение — DST IP в пакете меняется на нужный, и он отправляется получателю, плюс в обратную сторону то же самое.
                                                    Тот NAT, который в IPv6 становится не нужен — это маскарадинг, когда все хосты во внутренней сети использут ТОЛЬКО приватные адреса, и выходят в интернет через единый шлюз, используя единственный выданный провайдером внешний адрес на всех. Маскарадинг — это достаточно хитрый костыль, и у него есть свои ограничения и недостатки, при этом он на самом деле решает лишь одну-единственную насущную проблему, остро выраженную именно в IPv4: нехватку публично доступных адресов.
                                                      0

                                                      По-моему, он решает проблему представления одной сети в другой одним адресом. исторически так сложилось, что самое частое использование: первая сеть — частная, вторая — публичная.

                                                        0
                                                        Безусловно, он её тоже решает. И в IPv6 она тоже решается, просто немного другими средствами, и необходимость в этом возникает не так часто.
                                                          0

                                                          Как я понимаю, возникает она не так часто, если согласен, что девайсы в локальной сети будут иметь не локальные адреса, а из выдаваемой провайдером "навечно" подсети (пока платишь, пока сам провайдер существует, пока живешь в том месте, где он эту подсеть обеспечивать может)

                                            0
                                            Разница между полноценным firewall и NAT as firewall как между динамической и статической типизацией. Во втором случае вы просто синтаксически не можете сделать запрещенную операцию. А в первом случае вам нужны а) грамотные настройки фаеровола b) некий аналог юнит тестов на ваш фаервол, иначе как вообще узнать, что он работает?

                                              0
                                              > И именно правильно настроенный файрволл от этого защищает. А настраивать FW на каждой машине внутри сети не нужно: достаточно правильно настроенного FW на роутере.

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

                                              (1) Если файрволл будет просто не пускать входящие соединения вне белого списка, то эти приложения не будут работать.

                                              (2) Если файрволл будет пускать всех внутрь, кто знает адрес, полагаясь на качество рандома в MAC и временных адресов SLAAC, то будут массовые атаки по принципу «увидели неважно где чужой IP — испытаем его на все известные дыры».

                                              (3) Если файрволл будет следить за проходящими данными, то (если это вообще возможно — сейчас любят всё криптовать) ему потребуется интеллект на каждый такой протокол, и улучшение после NAT только в том, что не надо делать подмену адресов.

                                              Вариант (2) можно было бы решить разделением банднинга портов на случаи «Any для всех адресов» и «Any для постоянных адресов», но никто пока даже не начал делать пробы в этом направлении.

                                              Реально остаётся после этого только усиление файрволла через PCP, SOCKS или аналоги. UPnP не предлагать — протокол с XML и SOAP непригоден для IoT и мелкого embedded.

                                              И это мы ещё не вспомнили проблемы внутреннего DNS, в котором в идеале и временные адреса должны как-то отражаться.
                                                0
                                                Эти проблемы ведь никак не решаются NAT-ом? Я не говорю, что файрволл — панацея, но NAT не поможет всё равно — значит, NAT не нужен. Сам по себе NAT, который широко используется в домашних v4 сетях на сегодня, накладывает дополнительные ограничения, от которых с переходом на v6 можно отказаться, не вижу причин этого не делать.
                                                Ну, или я что-то не так понял.
                                        0
                                        А нат на v6 не предусмотрен по идеологическим соображениям? Ну на случай, если хочется. Я просто не в курсе.
                                          –2

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

                                            0
                                            И правильно делают, кстати говоря.
                                            +2
                                            Согласно идеологии IPv6 NAT это лишнее. Есть всякие NAT66, но поддержки в устройствах «домашнего» уровня я не встречал.
                                            Для внедрения IPv6 адресов предлагается политика deny-to-all, с ручным добавлением исключений. Но беда в том, что настройки сетевых правил доступны далеко не на всех устройствах. IoT в итоге остаются беззащитными, так как во многих случаях нет технической возможности добавить не то что шифрование, но и примитивную авторизацию.
                                            Любой современный firewall на роутере позволяет сделать фильтрацию для входящих пакетов и теоретически защитить внутреннюю сеть.
                                              +1
                                              В linux есть, еще с ядра 3.9.
                                                0
                                                Он предусмотрен, просто не нужен. Всё, что можно сделать при помощи NAT в IPv6, можно сделать и без него. Единственная причина его использовать — это «ну очень хочется». Причин хотеть его использовать нет, особенно если вы не сетевой инженер какой-нибудь организации, а настраиваете сеть дома.
                                                  0

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

                                                    0

                                                    точно так же, пробросом портов. NAT для этого не нужен.

                                                      +1

                                                      Ну, технически, это все-таки будет NAT-ом (адреса в пакетах меняются все-таки). Просто не таким сложным, как в случае с IPv4. А просто и тупо заменяем один адрес на другой и отправляем дальше, не занимаясь разными connection tracking.


                                                      Хотя лучше бы взять одну из подсеток из твоей /56, /48 специально для адресов публичных сервисов, назначать адреса из нее на том хосте, где сервис живет. А на маршрутизаторе прописывать маршрут "этот адрес — вон на том сервере".

                                                        0

                                                        Проброс портов для меня и есть NAT в целом, подмена адресов в пакетах.

                                                          0

                                                          Это может быть TCP proxy, а не NAT.

                                                        +1

                                                        Уже писал тут где-то рядом. Тот адрес, который внешний на маршрутизаторе — он в случае с IPv6 вообще не должен для сервисов использоваться. Сервисы вешаются в отдельную подсетку, которая вырезается из тех адресов, что абоненту выданы. И это подсетка — она не из /64 с внешнего интерфейса.


                                                        Просто вот это желание использовать "внешний адрес" — это привычка от IPv4, когда адресов абоненту мало давали.

                                                          0

                                                          Пускай не внешний адрес маршрутизатора, но один внешний адрес для всех (ну или большинства) внутренних сервисов мне кажется удобнее, чем по одному внешнему адресу на каждый девайс, не говоря о на каждый сервис на девайсе. Хотя бы потому что без DNS пользоваться ipv6 просто нереально, по-моему, а каждому сервису свой внешний поддомен выделять и постоянно синкать его с внутренней де-факто адресацией сервисов, затратно по времени. Разве что поднимать и DNS сервер свой, указывать его для *.mydomain.home, и как-то поддерживать синк с адресами.


                                                          Да и в целом непонятно как организовывать конфигурацию сервисов в такой схеме. Вот поднимаю какой-нибудь nginx как морду к домашней файлопомойке. Сейчас всё просто: новой железке в доме привязываю в DHCP внутренний IP по MAC, а когда поднимаю публичный сервис на ней, то пробрасываю порт с этого IP, самому же сервису указываю listen 0.0.0.0:80. Если сервис переезжает на другую железку, то только на роутере IP меняю.


                                                          Как со схемой 1 ip для сервиса быть? Для каждого нового сервиса привязывать новый IP к MAC в DHCP, настраивать железку, чтобы на одной сетевой карте она несколько адресов по DHCP получала. Это знчение копировать в конфиг сервиса в listen, создать поддомен и туда же скопировать? Как-то сложно

                                                            +1

                                                            Так не надо ничего постоянно синхронизировать. Та подсеть, которая вам выдана (еще раз — это не то, что на внешнем интерфейсе) выдается практически навечно и не меняется. Соответственно, поднимаешь сервис, выбираешь для него IP из сервисной сети. Прописываешь IP в DNS и больше оно никогда не меняется.


                                                            Работает это все дорожно приблизительно так:


                                                            На внешнем интерфейсе маршрутизатора провайдер дает, скажем
                                                            2001:db8:0:0:aaaa:bbbb:cccc:dddd (любым способом). Этот адрес никого не интересует и может быть более-менее произвольно провайдером меняться


                                                            Одновременно он выдает клиенту 2001:0db8:0000:ee00::/56 и маршрутизирует ее на этот адрес.


                                                            Клиент берет одну из /64 (например, 2001:0db8:0000:ee10::/64) в качестве адресов внутреннего сегмента для своих устройств — из нее адреса устройства будут автоматически получать. Если не страдать паранойей — всегда одни и те же, т.к. по MAC адресу генерироваться будут.


                                                            Еще одну сетку /64 (например, 2001:0db8:0000:ee11::/64) выбираем для для адресов сервисов.


                                                            Теперь что делаем, когда поднимаем сервис:


                                                            Есть у нас устройство, где сервис хотим поднять с адресом 2001:0db8:0000:ee10:1234:5678:9abc:def1 — это адрес постоянный внутри сегмента


                                                            Выбираем адрес из сервисной сети (2001:0db8:0000:ee11:2345:6789:abcd:ef01/128), вешаем его статиком на интерфейсе того устройства, где сервис живет (т.е рядом с 2001:0db8:0000:ee10:1234:5678:9abc:def1).


                                                            Прописываем 2001:0db8:0000:ee11:2345:6789:abcd:ef01 в DNS в виде servicename.mydomain.home


                                                            На маршрутизаторе прописываем маршрут 2001:0db8:0000:ee11:2345:6789:abcd:ef01 via 2001:0db8:0000:ee10:1234:5678:9abc:def1 и открываем нужные порты


                                                            Все.


                                                            Когда хотим сервис на другую железку перенести — переносим 2001:0db8:0000:ee11:2345:6789:abcd:ef01/128 уже на нее и меняем маршрут.

                                                              0

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


                                                              Всё руками настраивать. DNS становится обязательным, хорошо если провайдер будет давать его "бесплатно" и он будет более-менее человекочитаемым, вернее запоминаемым и, главное, UI в ЛК для настройки поддоменов. Вариант — свой DNS-сервер в домашних роутерах с UI уровня "домохозяйки".


                                                              Но даже всё это не избавит от необходимости синхронизировать три точки конфигурации:


                                                              • статику на устройстве
                                                              • этот адрес в DNS
                                                              • этот адрес в конфиге сервиса

                                                              Ну и куча открытых вопросов типа смена провайдера. Все же эти статики, DNS и конфиги переконфигурировать придётся. Ладно, если планово раз в несколько лет. А если это резервный канал? Сейчас я только кабеля в другой роутер подключаю или сетку wifi другую выбираю — внутри вообще ничего не меняется (кроме адреса шлюза по DHCP), снаружи другой IP. Вряд ли провайдеры будут предоставлять, по крайней мере "бесплатно", услугу маршрутизации с выданного им адреса роутеру на подсеть другого провайдера.


                                                              Как по мне, проблему мог бы решить какой-то единый DNS+DHCP сервис, когда пользовательский сервис (не девайс) запрашивает аренду адреса у него для конкретного домена. Если взять nginx то в рамках server_name можно сделать с каким-то флагом lease. но что-то сомневаюсь, что кто-то серьёзно нат этим думает.

                                                                0

                                                                При должной автоматизации точка синхронизации одна — адрес, записанный в DNS. А в остальных местах он может проставляться по читаемому имени.


                                                                Сценарий с резервным каналом — надо смотреть, как адреса назначаются в том префиксе, что провайдер отдал.


                                                                Если руками — то у сервисных сеток и адресов у сервиса будет по две штуки. Из адресов одного провайдера и из адресов другого.

                                                                  0

                                                                  Не умеют большинство сервисов резолвить DNS для listen. Да и обычные DNS пушить изменения не умеют вроде как. Целая система типа k8s нужна, по-моему, которая будет вести реестры mac-ipv6-dns, обновлять конфиги сервисов типа nginx и *sql и рестартовать/релоадить их. На баш-скриптах такое, по-моему, в юзабельном виде не напишешь. Может ansible какой-нибудь запускать по хрону, если минутный даунтайм не проблема в целом, как-то разделять адреса listen в шаблонах конфигов на подсеть и адреса в ней и т. п. В общем тривиальной задача не выглядит.

                                                                    0
                                                                    Хм, лучшая автоматизация — отсутствие автоматизации, т.е. нормальный рабочий NAT (или автономная система для большого сетевого хозяйства).

                                                                    Что до жизни с DHCPv6-PD, то тут Вы совершенно правы, если он есть, то выделяемая сеть и выделеный адрес это немного разное. Одна беда, половина поставщиков Интернет DHCPv6-PD знать не знают.

                                                                    Например, МТС его не поддерживает, типа всё равно DHCPv6-PD реальных проблем клиентов не решает и никому, на самом деле, и не нужен.
                                                      +1
                                                      > «белые IP» и соответственно проблемы с безопасностью

                                                      Мне рядом доказывали, что при правильной настройки этой проблемы нет за счёт того, что:

                                                      1. На обычный компьютер выдаётся какой-то постоянный адрес (link-local, site-local) для внутреннего общения, и случайный адрес через SLAAC (64 младших бита случайны), и этот случайный адрес живёт недолго (например, от 5 минут до часа).

                                                      2. Пока такой временный адрес занят на каком-то сокете, он сохраняется стеком, и таких может накопиться много, но как только последний пользователь его освободил — адрес отпускается стеком.

                                                      3. И после этого файрволл не нужен вообще — можно свободно заводить открытый слушающий порт и раздавать его, потом закрыл и пошёл дальше.

                                                      На первый взгляд выглядит разумно, но у меня с ходу вопросы: пусть, например, CIFS слушает на *:445 — будет ли он принимать соединения на такой временный IP адрес тоже? Если да, то атака типа «к нам кто-то пришёл — тут же проверим его на все дыры» будет работать.
                                                      Получается, что нужно два варианта байндинга на any: на «any вообще все» и «any открытые в момент байндинга»?

                                                      Я там ещё не комментировал, но вопросы на подумать уже есть.
                                                        0
                                                        1. Очень часто клиенты берут себе 1 локальный и 2 глобальных адреса. Один глобальный постоянный, для работы на приём в качестве сервера, а другой — переменный для хождения по интернету в качестве клиента.
                                                        3. Firewall нужен. Чтобы открыть на вход только те порты, что нужно. Остальное лучше закрыть для внешних сетей (для своей можно сделать исключение).
                                                        Современные приложения и сервисы по дефолту слушают на обоих протоколах и на всех имеющихся адресах. Но если этот сервис требуется только для изнутри своей сети, то можно в конфигурации например, SSH написать, что слушать только IPv4. И всё, вы за НАТом, и не надо глобально отключать IPv6.
                                                        Ещё раз, ещё много-много раз: вопросы безопасности решаются прежде всего фаерволом. А не временной кривизной программ.
                                                          +1
                                                          > Очень часто клиенты берут себе 1 локальный и 2 глобальных адреса. Один глобальный постоянный, для работы на приём в качестве сервера, а другой — переменный для хождения по интернету в качестве клиента.

                                                          Я по сути это и писал, с уточнением, что эти временные адреса могут задерживаться.

                                                          > Firewall нужен. Чтобы открыть на вход только те порты, что нужно. Остальное лучше закрыть для внешних сетей (для своей можно сделать исключение).

                                                          Как вы определите, какие порты надо открывать файрволлу? Есть немало протоколов, по которым клиент открывает приём соединений к себе, а не только от себя. Например, представьте себе VoIP с медиапотоком по TCP или SCTP в обход центрального прокси/регистратора, вполне нередкий вариант.

                                                          Если внешний файрволл существует и пропускает потому, что знает протокол и запомнил, подслушав, что открыт порт на приём… такой файрволл должен знать все протоколы (нереально).

                                                          Если он не знает протокол, но не пропускает входящие соединения — связи не будет.

                                                          Если он не знает протокол, но пропускает всё в сторону внутреннего хоста, полагая, что случайности IP адреса достаточно — то он может пропустить что-то на тот порт, на который ничего входящего не ожидается.

                                                          Выбирайте.

                                                          > Ещё раз, ещё много-много раз: вопросы безопасности решаются прежде всего фаерволом.

                                                          См. выше. И от написания «ещё раз» такие доводы не станут убедительнее.

                                                          > А не временной кривизной программ.

                                                          И откуда вы про «кривизну» взяли — мне тоже непонятно.
                                                            0
                                                            Про фаервол — он работает точно так же, как и раньше, как и для IPv4. Ведь научились же фаерволы пропускать входящие established and related. И не надо знать все протоколы, ведь в IPv4 вы этого не требуете.
                                                            Всё точно так же, только без NAT. А если фаервол находится между своей сетью и внешним роутером, который и раздаёт IPv6 префиксы, то тогда надо ещё открыть до 5 мультикастовых портов для neighbour discovery. Это аналогично открытию для запросов/ответов DHCP в варианте IPv4.
                                                            Вопрос с разными потоками данных решается точно так же, как и в IPv4, за минусом NAT и разных NAT-преодолевательных сервисов типа TURN.
                                                            Принимается решение для каждого компьютера, какую сетевую политику к нему применять, и соответственно этому решению открывать доступ снаружи.
                                                            Если у вас слабый/неудобный фаервол, то вы замучаетесь его настраивать во всех протоколах, а если мощный/дорогой, то там уже всё продумано до вас и вам там просто надо будет нажать пару кнопочек.
                                                              0
                                                              > Про фаервол — он работает точно так же, как и раньше, как и для IPv4. Ведь научились же фаерволы пропускать входящие established and related. И не надо знать все протоколы, ведь в IPv4 вы этого не требуете.

                                                              Established — понятно, говорите только про исходящие соединения или полученные другой магией. Откуда related-то возьмётся?

                                                              > Принимается решение для каждого компьютера, какую сетевую политику к нему применять, и соответственно этому решению открывать доступ снаружи.

                                                              Что, серьёзно для каждого? Из пусть пары сотен? На ходу? И как быть с теми же слушающими портами для медии?

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

                                                              Простите, я ожидал ответ инженера, который в состоянии обсудить именно механизмы работы, их специфику, преимущества и недостатки, а не продавана, использующего примитивные приёмы завлечения, и главное для которого — чтобы купили, а не правдивость его рассказов.
                                                              Спасибо за откровенность, не вижу смысла с вами это дальше обсуждать.
                                                                0
                                                                Откуда related-то возьмётся?

                                                                Это тоже кнопочка такая. Даже в микротике она есть. И во вкладке IPv6 там она тоже есть.
                                                                Для сотен серверов используются соответствующие корпоративные фаерволы. Которые давно умеют интегрироваться с LDAP/AD, управляются централизовано и выполняют корпоративную политику. Всё уже давно придумано за нас. И слушающие порты там тоже можно сконфигурировать один раз сразу для всей группы серверов.
                                                                Просто мне не верится, что вы настолько отстали от времени.
                                                        0
                                                        Белый IPv6 != белый IPv4.

                                                        На белом IPv6 у меня за пол года ни одной левой попытки войти на SSH. А вот на IPv4 даже fail2ban не помогает…

                                                        И тут проблема именно больших чисел — ну не реально (в сегодняшних условиях) сканировать IPv6 диапазонами хоть сколько-либо реального размера (по отношению к полному объему адресного пространства). А вот полный диапазон IPv4 сканируется за разумное время.
                                                        –1
                                                        Hetzner на убогую виртуалку выдаёт сеть /64. Мне на этой виртуалке эти адреса в таком количестве зачем нужны?
                                                        Просто спамеров банят сразу по /64 подсетям. Поэтому, если выдавать по одной штучке, огребут все, кто со спамером в одной /64 подсети.
                                                        Да, это очень хреново, но такова реальность. Видимо, кто-то от щедрости раздавал сразу /64, и спамерам это очень понравилось. Каждый день новый айпи, грубо говоря.
                                                          +12
                                                          Не «кто-то», а по стандарту положено /64 раздавать
                                                            0
                                                            Более того банят по /64
                                                          +12
                                                          Или «сверху» поставлен план утилизировать адреса за 10 лет, стахановскими темпами?

                                                          По стандарту на одну машину выдается сеть /64, а на несколько уже целых /48. Моей квалификации не хватает, чтобы сказать причины, но их настолько много, что можно раздавать настолько огромными сетями и они не закончатся. И даже если мы что-то сделали неправильно, у нас еще зарезервировано 7/8 сети, которые никак и никому не распределяются на этот случай.
                                                            +3
                                                            Чтобы оно заработало приходится открывать ICMP на широкие диапазоны серой сети и локальную подсеть для белой. Если сидишь хостинге в одном L2 сегменте с группой фиг пойми кого — это страшно.

                                                            А что именно страшно?


                                                            Hetzner на убогую виртуалку выдаёт сеть /64.

                                                            Но разве это проблема IPv6?


                                                            Не видел исчерпывающего описания IPv6.

                                                            Вот, например: https://yarique.bitbucket.io/ipv6_ru/ipv6_ru.htm

                                                              0
                                                              2. Hetzner на убогую виртуалку выдаёт сеть /64.

                                                              Это вы не поняли. /64 выдаётся не на один сервер, а на одного клиента (абонента, договор обслуживания). Это видимо, у вас всего один сервер. А сеть /64 выдаётся на все ваши сервера, находящиеся в выданной вам локальной сети. И домашним клиентам тоже положено выдавать как минимум /64 и снабжать это SLAAC.
                                                              Неисполнение этого выявляет непомерный жлобизм провайдеров, которых давно никто не учил правильному отношению к клиентам.
                                                              А у меня было 2 своих времени. Первое было совсем давно (IPv4). А во второе своё время я просмотрел божественный видеокурс лекций по IPv6, после которых он мне не страшен.
                                                              Более того, когда на моём сервере провайдер вдруг сменил адрес в одном из протоколов, мои клиенты смогли с задержками, но подключаться по другому протоколу. HTTP(S) от Apache. Как тут сообщают, эрэфийский джинс (nginx) позорно не умеет работать в double stack. Apache же прекрасно обслуживает оба протокола из коробки.
                                                                +2
                                                                Как тут сообщают, эрэфийский джинс (nginx) позорно не умеет работать в double stack.

                                                                То, что автор не осилил прочитать справку по директиве listen, ничего не говорит об nginx. На всех моих ранее упомянутых серверах стоит nginx, и на все его сайты успешно ходят юзеры и по IPv4, и по IPv6.

                                                                  0

                                                                  Дело не в справке, ее как и прочитал, просто доступ к настройкам nginx только у хостинга, так как у меня там простой аккаунт, а не vps. Насколько я знаю у них там вообще адская смесь, и nginx только для статичных файлов и ssl используется. Я особо не вникал в их кухню, но скорость работы сайта меня устраивает более чем — ведь скорость загрузки страницы вписывается в требуемые гуглом 100мс, причем без memcashed и прочего. А париться с техподдержкой хостинга, понимая к тому же что это общие настройки для всего хостинга с десятками тысяч сайтов, я не хотел.

                                                                  0
                                                                  А что за божественный курс, не поделитесь ссылкой?
                                                              0
                                                              Столкнулся с нюансами IPv6 на своих серверах. Всё работает вроде локально, а через несколько часов при заходе на сайт — домен не существует. Отключаю IPv6, всё приходит в норму. Включаю обратно, мониторю, пропадают первыми субдомены, затем и домены. Через 8.8.8.8 это происходит быстрее всего. Чистки кэша GoogleDNS результата не дают.
                                                              Оказалось, что bind не слушает на IPv6, хотя настройки в норме. Обнаружил ключ запуска демона, который принудительно включает только IPv4 (centos7 если что). После приведения в порядок все работает отлично.
                                                              Предполагаю, что Google в приоритет ставит IPv6 и если в зонах прописаны имена, а ответа нет, то возникают проблемы.
                                                              Так что первым делом на серверах проверяйте работают ли демоны на IPv6 через netstat и проверяйте доступность доменного имени через различные сервера.
                                                                +3
                                                                Если у вас авторитетный нейм-сервер прописан с ipv6, а в действительности он по тому адресу не слушает — это логично, что часть запросов будут фейлиться.
                                                                +4
                                                                Могу сказать, что настроенный dual-stack с нативным ipv6 (провайдер выдаёт через radvd) — отлично работает. Всё, что поддерживает v6, коннектится именно туда, а всё, что v4 — как и было раньше, без проблем. В основном, правда, этот протокол используют Гугл и Яндекс… Ну и некоторые клиенты Хецнера, да.

                                                                А если у вас нет нативного ipv6 и требуются какие-то брокеры — не извращайтесь, технически это примерно то же, что построить VPN чисто для ipv6, со всеми прилагающимися проблемами.
                                                                  +9
                                                                  В опросе не хватает варианта «настроили v6, про v4 не забывали, работаем на dualstack, проблем нет» )
                                                                    0

                                                                    Первый пункт как раз и подразумевает ваш вариант, ведь без ipv4 сейчас вообще никак, просто в опросе заложены небольшие крупицы юмора :)

                                                                    0
                                                                    Да, с брокерами заметил дикие тормоза, особенно почему-то с Фейсбуком. Хотя нахожусь в Европе, до шлюза брокера 5мс, и гигабитный канал, но не судьба :(
                                                                      0

                                                                      Я на Ютубе заметил что часть видео просто не загружаются через брокерский IPv6. Ошибка 403 и всё тут. Будто бан какой-то. По IPv4 всё нормально...

                                                                      0
                                                                      Нативный v6. Netflix почти всегда недоступен по v6 через андроид. К сожалению баг приоритета v6 в андроиде закрыт с wontfix. Соответственно иногда открытие netflix app просто вешается вплоть до перезагрузки девайса.

                                                                      Иногда вообще весь V6 вешается по какой-то странной причине (я предполагаю рутер TP-Link барахлит) и приходится перегружать все.

                                                                      С youtube проблема наоборот, опять же с мобилы сайт не открывается или дико тормозит, только через app.
                                                                        0
                                                                        >опять же с мобилы сайт не открывается или дико тормозит
                                                                        В полной версии у всех тормозит. В мобильной все работает. ipv6 никак на это не влияет.
                                                                        >Netflix почти всегда недоступен по v6 через андроид
                                                                        У меня все работает, это у вас проблема.
                                                                    +15

                                                                    Не умаляя преимуществ v6, порог вхождения в него для большинства слишком высок и за все эти годы не предпринимается никаких попыток что-то упростить или автоматизировать. Для меня, как простого домашнего пользователя, с v4 всё элементарно: есть провайдер, дал мне внешний v4 адрес, дальше в роутере я включаю nat, включаю DHCP для домашней локалки, по желанию биндю статично адрес на mac и напоследок пробрасываю порты. Всё! просто, наглядно, прямолинейно.
                                                                    А что v6? решил я включить v6 через Hurricane Electric. Открыл (к счастью имеющуюся в роутере) веб страничку настроек, вбил диапазоны, а дальше начинается какая-то магия: клиенты сами получают адреса, причем и какие-то статичные и динамичные, анонсы от роутера то идут, то не идут. В виртуалках то работает, то нет. Где какой гейтвей, как работает маршрутизация, как работает доступ извне, работает ли файрволл, стали ли все мои компы смотреть в мир голой опой? Для меня абсолютный чёрный ящик.
                                                                    Безусловно, что на все эти элементарные для сетевика вопросы, можно найти ответы, я ж не спорю. Но уровень сложности и нюансов топологии настолько вырос, что, если в v4 понимал любой школьник, а по большому счёту все домашние роутеры уже настроены по принципу включил и оно работает как надо из коробки, то с v6 ситуация просто небо и земля, и для его понимания действительно нужно либо серьёзно прокачиваться, ибо применить имеющиеся знания "по аналогии" невозможно, либо кардинально менять выпускаемое оборудование в плане оптимизации UI и перевода процесса настройки в простые и понятные истины, но этим вообще никто и не думает заниматься.


                                                                    С хостингом ситуация не лучше… К сожалению, суровая реальность такова, что кроме сотни самых крутых и богатых компаний в стране есть тысячи других мелких, которые тоже должны содержать свои сайты и сервера, но не могут позволить себе профессионально обученного сетевого инженера для грамотной настройки v6. Поэтому для них решение одно — не использовать ввиду тотальной боязни оказаться снаружи с голой опой или иных внезапных проблем со связностью, коих с v4 возникает намного меньше или хотя бы намного проще нагуглить их решение и best practices

                                                                      +1
                                                                      Да ещё и у лучших роутеров для дома нет нормальной поддержки IPv6.
                                                                        0
                                                                        OpenWRT дома отлично работает
                                                                          0
                                                                          И позволяет настраивать всё из GUI? Например, выдачу IPv6 по мак-адресам, роутинг? Я бы не отказался от выборочного адвертайзинга, по разным устройствам.
                                                                            –2
                                                                            Насчёт GUI я не знаю, хожу на свой роутер через SSH. И там всё вами перечисленное есть, и RADVD и DHCPv6 и iptables6 и sit (ip6-in-ip4) в любой комбинации какую пожелаете. Потому что, очевидно, OpenWRT является более-менее полноценным дистрибутивом Linux.
                                                                              +5

                                                                              Т.е. это актуально для количества людей за пределами статистической погрешности.

                                                                                –1
                                                                                Мне так кажется, что если ваши потребности переросли возможности вашего роутера, то вполне естественным будет искать пути расширения этих возможностей, независимо от того, в какое промилле вы себя относите.
                                                                                И OpenWRT тут далеко не самый дорогой и сложный путь.
                                                                                  +1

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

                                                                                    0
                                                                                    Торренты из-под NAT работают так себе. Наличие в стайке IPv6 пиров бывает, ускоряет загрузку значительно.
                                                                                      0
                                                                                      Честно говоря, не замечал за много лет пользования торрентами и под виндами и под линуксом.
                                                                                      Причём порт не проброшен, UPnP выключен, NAT, стейтфул файрвол и тянет всегда чётко 100 Мбит/с, дальше уже не куда, канал такой.
                                                                                      Правда на внешнем интерфейсе всегда был «белый» адрес, то есть у провайдера NAT не использовался.
                                                                                      Да и вообще, с учётом распространения стриминговых сервисов, торренты становятся признаком гика.
                                                                                        0
                                                                                        распространения стриминговых сервисов

                                                                                        Не один стриминговых сервис не обеспечит качество как на Blu-ray. А на торренте есть полный образ blu-ray с Dolby Vision и TrueHD. А для музыки есть Tidal, это да.
                                                                                          +1
                                                                                          Не один торрент не обеспечит качество как на Blu-ray.
                                                                                          Очень странное утверждение, учитывая что образы блюреев вполне себе распространяются через торренты.
                                                                                          А ещё, что невооружённым глазом вы врядли отличите качественный BDRip от оригинала.
                                                                                            0
                                                                                            Я опечатался, «стриминговый сервис»
                                                                                            0
                                                                                            На торрентах достаточно посмотреть на количество пиров у полуторагиговых рипов и у образов блюреев, различается в сотни раз в пользу первых. Так что оно то там конечно есть, но большую часть потребителей устраивают полуторагиговки, мутные экранки с рекламой и стриминг. О чем и речь.
                                                                                              +1
                                                                                              О, это вряд ли. Более вероятно, что из-за многократно большего размера файлов, их и сидят меньше — скачивают, смотрят и удаляют.
                                                                                                +1
                                                                                                Достоверно насчёт торрентов мы не сможем подтвердить или опровергнуть, есть только цифры с трекера и они показывают то, что показывают. А кто там чего удаляет это только догадываться можно.
                                                                                                За себя скажу, что качаю именно полуторки, не вижу смысла в огромных файлах, если фильм ерунда, то ему никакое 4к не поможет, а если хороший, так он и мутной экранкой смотрится.
                                                                                                А рост популярности стриминговых сервисов вроде очевидный факт.
                                                                                0
                                                                                Это не заложено в дизайн IPv6, а значит будет маргинальной фичей.
                                                                                  0
                                                                                  Формирование адресов из МАК-адресов заложено в дизайн IPv6. Через это формирование формируются квази-постоянные адреса IPv6.
                                                                                    0
                                                                                    В посте выше говорится так, словно человек хочет назначать произвольные адреса (типа как «статический DHCP» в v4) c CPE на устройства, которые ему придут в голову. Именно про эту «незаложенность» я и говорил.
                                                                                      0
                                                                                      Можно вручную конфигурировать любые статические адреса в пределах выделенного префикса.
                                                                                      Можно ещё добавить/установить/сконфигурировать DHCPv6 сервер, который тоже умеет выдавать заранее зарезервированные для МАК-адресов произвольные квази-статические адреса.
                                                                                      Но тут выбор будет побогаче: можно иметь и SLAAC, и DHCPv6 одновременно. Что в реальности будет происходить, зависит от реализации сетевого стека в каждом клиенте.
                                                                                      Например, гуглу очень не нравится DHCPv6 — телефоны отказываются брать от него адреса. Но это — наглая выходка большой конторы, которая может позволить себе плевать на стандарты и на корпорации.
                                                                                        0
                                                                                        Например, гуглу очень не нравится DHCPv6 — телефоны отказываются брать от него адреса.
                                                                                        Лолшто. Вы имеете в виду Android? У меня дома dnsmasq на OpenWRT отлично раздаёт им настройки как DHCPv6, включая дополнительный DNS сервер и статику v6 с привязкой к DUID. Никогда с этим не встречал проблем.
                                                                                    0
                                                                                    Формирование IPv6-адреса по MAC заложено ещё с самых ранних времён: для MAC x:y:z:p:q:r строится адрес, 8 младших октетов которого — (x^1):y:z:FF:FE:p:q:r. Для link-local адресов это единственный нормально разрешённый вариант, для остальных — умолчание, если ничего иного не установлено явной настройкой.

                                                                                    В ранних планах вообще предполагалось избавиться от Ethernet-уровня и использовать IPv6 адрес как единственный и на канальном уровне. Но потом как-то обломилось и сейчас в IPv6 введены снова MACи и аналог протокола ARP.
                                                                                      0
                                                                                      В посте выше говорится так, словно человек хочет назначать произвольные адреса (типа как «статический DHCP» в v4) c CPE на устройства, которые ему придут в голову. Именно про эту «незаложенность» я и говорил.
                                                                                        0
                                                                                        Выдавать произвольные адреса — типа $netbase::123 — тоже можно, но уже, насколько помню, только через DHCPv6, а не через обычный solicitation.

                                                                                        $ host ns.ripe.net
                                                                                        ns.ripe.net has address 193.0.9.6
                                                                                        ns.ripe.net has IPv6 address 2001:67c:e0::6
                                                                                        

                                                                                          0
                                                                                          А через DHCPv6 нельзя выдать префикс, так что нужно и то, и другое.
                                                                                          То есть повторяю свой посыл — это не заложено изначально.
                                                                                            0
                                                                                            DHCPv6 Prefix Delegation (DHCPv6-PD)

                                                                                            И пока поставщики домашнего Интернет хотя бы этому не научатся, без NAT жизни по-любому не будет.
                                                                                    0

                                                                                    Из веб-интерфейса поддерживается и выдача клиентам суффиксов DHCPv6 по макам или хостнеймам, и роутинг IPv6, и настройка интерфейсов с IPv6 по куче протоколов.
                                                                                    А если чего-то в штатной сборке не хватает, то можно из веб-интерфейса же поставить новые пакеты для настройки через веб к какому-либо ПО, которые автоматом подтянут за собой само это ПО.


                                                                                    Вообще, нынешний OpenWRT не особо требует лазить в терминал, если нет такого желания.
                                                                                    В последнее время сталкивался с безысходным путем в терминал дважды.
                                                                                    Один раз когда настраивал vpn-сервак на Vultr на базе OpenWRT — там для моих заморочек с файрволом потребовался macvlan, для которого морды нет. Другой — возникает периодически, если ставить https-dns-proxy, и хочется поправить его конфиг. Для него тоже морды нет.
                                                                                    Короче, типичный домохозяин настроит его из браузера, и не очень поймёт, что это был OpenWRT.

                                                                                    +6

                                                                                    мораль была как раз в том, что если технология работает ТОЛЬКО на OpenWRT, то она обречена только на специфические решения для гиков. Если фича позиционируется к использованию на 100% оборудования, то и работать она должна на стоке и желательно не только в CLI. Но вендоры не чешутся, и имхо — это один из главных факторов, сдерживающих популяризацию.

                                                                                      0
                                                                                      Ну так технология не виновата в том, что вендоры не чешутся. А не чешутся они потому, что нет спроса. А спроса нет, потому что юзеры неинформированы.
                                                                                        +3
                                                                                        А спроса нет, потому что юзеры неинформированы.

                                                                                        А в чем выгода для конечного пользователя? Не гика? Это очень сложно объяснить, ведь на ipv4 и так почти все работает без проблем.

                                                                                          +4

                                                                                          Не информированы о чём? О наличии ip6 в принципе? А зачем он им, даже если будут информированы? Вот когда перестанут нужные им сайты и приложения работать по ip4, тогда и зачешутся… а пока даже я, довольно информированный, не чешусь.

                                                                                      +3

                                                                                      да, при огромном уважении к ребятам, грустно видеть такую политику партии, не уделяющую достаточного внимания этой фиче. Просто надо понимать, что v6 в домашних роутерах — это не только бесполезная фича для домохозяек, но и удобный испытательный полигон для любого программиста или сетевика. Чтобы технология стала действительно массовой, особенно сложная, она должна заходить с самых низов, с самых простых и доступных уровней, как домашние сети, чтобы применение технологии начало откладываться в подсознании на уровне рефлексов. И да, это та самая социальная ответственность, которую хочется видеть от лидеров рынка, и пусть не прямой выгодой от красивой фразы на коробке, но нашей любовью за это и косвенной рекламой и советами к покупке такие решения всё равно должны окупиться.

                                                                                        0
                                                                                        Вроде говорят что v6 плохо, а точнее совсем не фильтруется цензурой. Я не проверял. Моя история закончилась тем, что штатно включить его у моего провайдера невозможно, надо куда-то далеко и долго звонить и объяснять, что ты хочешь. А у других провайдеров такого и вовсе нет даже в теории. Так что политика партии очень важная вещь, вероятно, стоит заморочиться.
                                                                                          0

                                                                                          у провайдеров, которые не поддерживают v6 сами, да, иногда не фильтруется. Поэтому подключив себе v6 через брокера, получаем маленький лайвхак )) Собссно я не просто так упомянул Hurricane Electric в своём посте выше ))

                                                                                          0
                                                                                          Когда много свободного времени и ресурсов — да, это верно.
                                                                                          А когда у тебя по данным всего у 3-4% абонентов вообще есть хоть какой-то IPv6 (включая 6in/to4), а другие фичи хотят большее число клиентов — приоритеты меняются.
                                                                                            0

                                                                                            помечтать не вредно )) да и мораль таки была в традиционной проблеме курицы и яйца… Удобный UI вполне может замотивировать сделать первый шаг и погрузиться в эту тему куда большее количество пусть не домохозяек, но любых хоть немного знакомых с IT чуваков. А там и пошло поехало, привычка, рефлексы и пойдёт в массы.
                                                                                            Ну, вобщем, в любом случае спасибо, что слушаете наши хотелки как никто другие )

                                                                                        0
                                                                                        Замените здесь «включить v6 через Hurricane» на «построить VPN», и «включить NAT с пробросом портов» на «настроить фильтрацию трафика при условии, что все машины в локалке получили белый IP» и вы получите то, с чем реально столкнулись.

                                                                                        … ну да, вряд ли домашние роутеры со стоковой прошивкой рассчитаны на такое…
                                                                                          +1

                                                                                          в том-то и засада, что переход на ipv6 условно двигает тебя на одну ступеньку выше в сетевой топологии: если сейчас у тебя (у любого домашнего хозяйства или единичного офиса) есть уютный замок с одними публичными воротами, то с v6 к тебе в каждый девайс приезжает следущий уровень, где уже действительно нужна маршрутизация, типо домового коммутатора и вот это всё — бывший уровень провайдера, который обслуживают специально обученные люди. Это, мягко говоря, не добавляет оптимизма

                                                                                          0
                                                                                          А что v6? решил я включить v6 через Hurricane Electric.

                                                                                          Мне кажется, вы сравниваете апельсины с яблоками. Вы же не включаете туннелирование в IPv4.


                                                                                          Я, когда решил настроить IPv6, нажал одну кнопку в интерфейсе. Может, две — файрвол включил.

                                                                                            0
                                                                                            А что v6? решил я включить v6 через Hurricane Electric.

                                                                                            Неправильное решение.
                                                                                            Оно само автоматически работает, ещё более элементарно: просто ничего не надо делать и по дефолту все устройства получают через SLAAC адреса и маршруты и работают. NAT не нужен, DHCP тоже редко когда требуется.
                                                                                            Для серверов тоже можно сконфигурировать статический адрес. Пробрасывать порты не нужно, вместо этого можно сконфигурировать фаервол, чтобы не «смотреть в мир голой опой».
                                                                                            Если оно само не работает, то у вас плохой провайдер, несовместимый с IPv6.
                                                                                            Мне так кажется, что в эрэфии много таких мест, где окончательным решением шестого вопроса является «завести трактор». Правда, для этого теперь придётся дождаться или выездной визы, или падения железного занавеса, запрещающего ВЫЕЗД граждан из страны РФ.
                                                                                              +1
                                                                                              > Оно само автоматически работает, ещё более элементарно: просто ничего не надо делать и по дефолту все устройства получают через SLAAC адреса и маршруты и работают.

                                                                                              ORLY? Где можно увидеть список умеющих такое устройств системы «домашний/SOHO раутер с рожками», ценой до 100$ и интерфейсом, пригодным для среднего чайника (условия жизненно важны, а то тут предложат опять строить openwrt по ssh)?

                                                                                              > Если оно само не работает, то у вас плохой провайдер, несовместимый с IPv6.

                                                                                              Провайдер ещё и должен был обеспечить клиента правильным раутером?
                                                                                                0
                                                                                                Аэропорт ORLY сейчас закрыт. Про устройства я так сразу не скажу, особенно про те, что для чайников. Хотя уже должны быть, ведь IPv6 уже давно и в америке и в европе есть у клиентов.
                                                                                                Но тут да, действительно, в европе обычно провайдер обеспечивает клиента правильным раутером. С укрупнением и монополизацией провайдеров они уже лет как 15 предлагают Triple-Play. Ихние провайдерские коробки выдают из себя IPv4 с NAT и wifi, IPv6 /64, телефонию с разъёмом RJ11 и телевидение через уже готовый HDMI. Пульт прилагается.
                                                                                            +8
                                                                                            Вы в опросе забыли про вариант «рад попробовать, но провайдер не дает»
                                                                                              +3

                                                                                              Имею IPv6 на всех своих серверах (в том числе у российских лоукостеров) — всё норм, 1% юзеров даже хотит по IPv6, жалоб о неработоспособности не получал


                                                                                              Дома провайдер ленится пилить IPv6. Пробовал подключать туннель от Hurricane Electric — как бы работает, но гугл задолбал своими рекапчами, пришлось отключить

                                                                                                +12

                                                                                                А кто-нибудь знает, откуда берутся туннельные брокеры, на чём они зарабатывают, как окупается трафик?

                                                                                                  –1

                                                                                                  По мне так вся эта история есть всемирный эпический фейл, как не надо делать технологии. Вместо того, чтобы просто расширить адреса, решили всех силой загнать в светлое будущее, и уже 20 лет загоняют. Переделать миллиарды устройств, переобучить миллионы инженеров, притом за их же счёт, всю архитектуру сети переделать — чтобы размер адреса увеличить?


                                                                                                  Это, кстати, к вопросу, что бывает, когда торжествует чисто инженерный взгляд на вещи, без учёта "бизнеса".

                                                                                                    +1

                                                                                                    А как просто расширить адреса? Это же в большей части аппаратная проблема.

                                                                                                      0

                                                                                                      Сделать новый формат пакета, а в остальном все оставить как есть. Железки все равно перепрошивать, спору нет, но одно дело — накатить апдейт, который просто включает ещё один новый режим, как TLSv1.2 -> TLSv1.3, но при этом все в целом работает точно так же, как и раньше, только лучше, а другое — переделать всю архитектуру сети под это дело.


                                                                                                      Индустрия десятки раз переходила на новые стандарты и протоколы, как программные, так и аппаратные (те же версии wifi или стандарты USB или тот же TLS), но все как-то обходились без необходимости разломать все кругом. Это если об этом всем думать, конечно.

                                                                                                        +2
                                                                                                        накатить update на аппаратную реализацию не получится
                                                                                                          0

                                                                                                          Если чисто аппаратная — да, ну заменить равно или поздно, роутеры вон меняют или базовые станции в сотовых сетях. При этом не требуется переделывать всё вокруг опять же. Вопрос же не в замене одной конкретной железки, а в том, что надо все железки, весь софт и все настройки обновить, и не постепенно, а именно что сразу, а пока это не сделано — система не работает. Это совсем не то же самое, что плавно все обновить, сохраняя обратную совместимость и постепенно оптимизируя.

                                                                                                            0
                                                                                                            Вопрос же не в замене одной конкретной железки, а в том, что надо все железки, весь софт и все настройки обновить, и не постепенно, а именно что сразу, а пока это не сделано — система не работает. Это совсем не то же самое, что плавно все обновить, сохраняя обратную совместимость и постепенно оптимизируя.
                                                                                                            Вообще-то есть такая вещь, как двойной стэк. Когда система работает одновременно и в IPv4 и в IPv6.
                                                                                                              0

                                                                                                              И почему же он у всех не работает из коробки? А должно быть из коробки, с околонулевыми затратами на обучение и настройку. Как версии TLS.

                                                                                                                +1
                                                                                                                В смысле не работает? Очень даже работает. Как только я на роутере поднимаю IPv6, все устройства в доме (windows + linux + android) его подхватывают и корректно работают с ним в двойном стэке. Только на Windows на всякий случай надо отключать teredo, но это одна команда всего.
                                                                                                                  0

                                                                                                                  И откуда же тогда описанные проблемы, с некоторыми из которых я лично сталкивался тоже? Напомню, технологии 20 лет, это вообще ни разу не что-то новое.

                                                                                                                    0
                                                                                                                    Я же говорю вам — инерция легаси это страшная штука. Вы помните, в каком релизе винды был окончательно выпилен NTVDM? Там явно побольше 20 лет прошло.

                                                                                                                    Малая информированность вкупе с малым спросом на поддержку IPv6 в роутерах SOHO сегмента пока что сужает диапазон доступных решений до гиковских типа OpenWRT. Но это — проблемы рынка и вендоров, а не архитектуры.

                                                                                                                    Кроме того, есть и инерция мышления разработчиков. Помните, как в 90-е и начале 2000-х при том, что поддержка Unicode в мэйнстримных ОС существовала уже многие годы, регулярно возникали проблемы с кириллицей в путях и прочих строковых данных? Потому, что по старинке разрабы фигачили в ANSI в американской локали, не задумываясь над тем, что далеко не весь мир использует латиницу. Так и сейчас — довольно небольшая часть разработчиков, пишущих сетевые решения, проектирует их так, чтобы они вписывались в экосистему IPV6 хотя бы в виде дуал стэка, не говоря уже о v6-only. Ну так разве это проблема архитектуры?
                                                                                                                      +1

                                                                                                                      У вас тут несколько просто прямо таких вопиющих вещей:


                                                                                                                      • естественно, пользователям нафиг не нужен IPv6, потому что он для них никаких преимуществ не даёт — ни скорости, ни качества, ни цены, ничего. Как и для провайдеров, да и вообще почти для всех. Странно даже, что никто не хочет покупать и настраивать не нужный им геморрой.
                                                                                                                      • пример с юникодом хороший — не было никакой вменяемой поддержки юникода почти нигде в конце 90-х — начале 2000-х. Винда 9х поддерживала его через пень колоду, в NT получше, но ещё долго были юникодные и не-юникодные билды, и все это устаканилось только к середине 2000-х, когда и вправду все заработало. И вот когда оно практически само из коробки стало работать — тогда все и взлетело. И при этом юникод решал реальную проблему, особенно с азиатскими языками, которая реально была неприятна.
                                                                                                                      • архитектура должна быть такая, чтобы в нее не надо было ничего дополнительно к четвёрке вписывать, а этом главная проблема. Буфер побольше сделать для адресов, где-то один раз включить — и всё.
                                                                                                                        +3
                                                                                                                        естественно, пользователям нафиг не нужен IPv6, потому что он для них никаких преимуществ не даёт — ни скорости, ни качества, ни цены, ничего.
                                                                                                                        it depends.
                                                                                                                        Если пользователь лезет в инет только котиков полистать и вконтачике поболтать, то ему да, всё равно, хоть за тремя NATами сиди, никакой разницы.
                                                                                                                        А вот минимально продвинутые юзеры начинают запускать какие-нибудь торренты или ещё что-то P2P что требует приёма входящих коннектов, или там ставят себе SIP-телефон, или упаси б-же поднимают у себя вебсервер с фотоальбомом любимой тёщи — и опаньки, начинаются свистопляски с UPnP, port forward, STUN и прочим говном, которое работает через раз и не в ту сторону либо для настройки которого нужно ровно столько же телодвижений, сколько и для поднятия IPv6.
                                                                                                                        Можете сходу предложить рабочее легко развёртываемое решение задачи «из едущего поезда зайти на домашний сервер» в экосистеме IPv4? Не, это, конечно, делается, но через попу.
                                                                                                                        А вот ещё совершенно реальная ситуация — ещё лет 10 назад провайдеры повально дифференцировали трафик на «международный» и «до местного IXа». Первый был значительно медленнее, вплоть до того, что там тарифные планы «30 мбит в мир против 100 на IX», второй быстрый и зачастую бесплатный. И тут в местныйй IX подключается IPv6 брокер, что сразу даёт преимущество и в цене и в скорости не только его клиентам, а всем кто рядом подключён.
                                                                                                                        Ну и так далее. Если подумать, преимущества есть.
                                                                                                                        И вот когда оно практически само из коробки стало работать — тогда все и взлетело.
                                                                                                                        Это переводится как «когда программистам стали регулярно давать по рогам за неподдержку Юникода». При том, что она была и работала, даже на 9х.
                                                                                                                        архитектура должна быть такая, чтобы в нее не надо было ничего дополнительно к четвёрке вписывать, а этом главная проблема. Буфер побольше сделать для адресов, где-то один раз включить — и всё.
                                                                                                                        Это примерно как решать переход с поршневой авиации на реактивную путём увеличения объёма двигателя и добавления одной кнопки, ага.
                                                                                                                          +2

                                                                                                                          Ну и в итоге,


                                                                                                                          • задачи с прямыми адресами были в итоге решены другими средствами
                                                                                                                          • когда есть ценность для пользователя осязаемая, за нее готовы платить и страдать.
                                                                                                                          • когда ее нет, а есть некое абстрактное улучшение, оно должно быть бесшовным максимально, если ставить цель успешность внедрения, а а не ЧСВ почесать (не в вас лично выпад).

                                                                                                                          Реактивная авиация давала плюшки, ради них можно все переделать. А IPv6 спроектирован, как будто это реактивный двигатель против поршневого, а на деле поставили титановую шайбу вместо стальной в подшипнике #135 — афигенно важно для пилота. А требуют самолёты перестраивать, притом за свой счёт.

                                                                                                                            0
                                                                                                                            задачи с прямыми адресами были в итоге решены другими средствами
                                                                                                                            Не были. «Изкоробочных» универсальных решений, дающих входную связность в условиях повального NATа везде как не было, так и нет и не будет. До тех пор, пока у всех вновь не появятся белые адреса, как уже один раз было в 90-х. IPv6 такую возможность даёт.
                                                                                                                            А IPv6 спроектирован, как будто это реактивный двигатель против поршневого, а на деле
                                                                                                                            Есть класс задач, где у него есть явные преимущества. То, что этот класс узок, не проблема архитектуры протокола. Я уже повторяюсь, кстати, и вы тоже.
                                                                                                                            0
                                                                                                                            Можете сходу предложить рабочее легко развёртываемое решение задачи «из едущего поезда зайти на домашний сервер» в экосистеме IPv4?

                                                                                                                            Все кому это надо, просто включили у провайдеров услугу фиксированного публичного IP адреса. Стоит не так дорого.
                                                                                                                              0
                                                                                                                              Стоит не так дорого.
                                                                                                                              Так мой оппонент тут возмущается за полную бесшовность и прозрачность миграции, а вы какие-то деньги платить предлагаете, за то же, что v6 бесплатно и «из коробки» умеет.

                                                                                                                              Кстати, обратная задача (домашнему серверу нужно срочно сообщить о взломщиках в квартире) в экосистеме IPv4 напрямую не решается вообще, требуются всякие сторонние транспортные сервисы пуш-уведомлений, смс или месенджеров, каждый из которых может упасть или задержать транзит и тому подобное.
                                                                                                                                +1
                                                                                                                                Как мне кажется, бесшовность и прозрачность никак не пересекаются с бесплатностью. Более того, некоторые провайдеры напротив берут деньги за IPv6.
                                                                                                                                По обратной задаче, так сотовая сеть может пропадать в куче мест, переходить в 2G, где дата трафик в угоду оставшемуся там голосу, просто почти не передаётся. Так что вопрос спорный. Гораздо большему количеству людей будет больше по душе бота в телеграме соорудить, чем писать какие-то свои приложения или поднимать, не знаю что там, личный джаббер, которые ещё и батарейку будут сажать гораздо сильнее пушей.
                                                                                                                                Опять же, личному джабберу не вижу, что может помешать подключиться к серверу дома. А писать под такие задачи приложение на мобилу видится слишком фантастическим сценарием.