IPv6 — прекрасный мир, стоящий скорого перехода на него +36





Практически все статьи, которые я видел на тему «чем хорош IPv6 и почему на него стоит пошустрее переходить», говорят только о просто более широком адресном пространстве. В лучшем случае, упомянут автоматическую конфигурацию адресов и маршрутов (stateless address autoconfiguration (SLAAC)). Это удручает, а ведь IPv6 имеет много ещё других неявных плюшек, являясь очень продуманным стеком протоколов (IPv6 + ICMPv6 + NDP)! Создаётся впечатление, что IPv6 это просто тупо про расширение адресов, а дальше то особо никакого профита. Или же некоторые статьи плачутся о том, что они не видят сиюминутного профита от внедрения/перехода. Простоту и удобство, гибкость и расширенные возможности (из-за одного только избавления от NAT-а) не так то легко измерить, как какие-нибудь задержки и пропускную способность. Решил поэтому собрать моё видение прекрасного мира IPv6 протокола и его плюсы в этой статье.

Не использовать IPv6 для построения чего-то нового, новых сетей — просто не имеет смысла, так как лишаемся массы удобств и возможностей, получая кучу геморроя от лишения этой массы удобств и возможностей. IPv6 поддерживается даже с Windows XP версии. Последний раз я проверял пять лет назад, но уже тогда SLAAC+RDNSS/DNSSL поддерживали и iOS и Android и даже Windows 10 устройства, не говоря о GNU/Linux и BSD системах.

IPv4 не является плохим протоколом. Его проблема только в том, что он никогда не задумывался для создания большой глобальной сети, где почти у каждого человека на Земном шаре будет доступ к ней прямиком из штанов (где лежит смартфон). Он создавался во времена, когда компьютеры были более быстрыми чем сети (странное сравнение?) и с кучей памяти. Сейчас наоборот: сделать 10 Gb канал связи можно тривиально и дома, но из коробки ни одна из массово используемых ОС не сможет эффективно коммутировать или маршрутизировать трафик на такой скорости.

Конечному пользователю сложно представить получаемые преимущества, так как Интернета, по факту, уже давно мало кому дают: преобладающая часть людей всегда сидела за NAT-ом и считает, что изобретение протоколов типа WebSocket, есть нечто штатное, нормальное, логичное и разумное, и ничего кроме TCP, UDP и ICMP у нас особо-то и не ходит поверх IP.

Сетевому инженеру, чисто психологически, сложно будет пересиливать себя в понимании того, что адресов и сетей реально очень много выдаётся и не имеет смысла (и даже будет только вредить удобству и простоте обслуживания) экономить на их использовании. Большая проблема — осознание того, что IP адреса уже не являются дефицитным ресурсом и думать приходится чаще всего в понятиях не единичных адресов, а целых огромных сетей минимум с /64 префиксом.

IPv6 имеет более серьёзные требования (эту часть можно обозвать недостатками):

  • Минимальный допустимый MTU канала: 1280 байт.
  • Канал должен быть с обнаружением (или даже исправлением) ошибок.
  • NDP протокол работает активно поверх multicast адресов, требуя работоспособных multicast рассылок в Ethernet-е.
  • PMTUD является обязательным для (эффективной) работы, так как в IPv6 нет фрагментации пакетов на уровне маршрутизаторов.
  • ICMPv6 протокол играет очень большую роль для работоспособности IPv6 сетей, как минимум для NDP и PMTUD — заблокировав его (как многие админы любят делать в IPv4 сетях), сеть, скорее всего, перестанет работать.

Что же даёт IPv6, какие плюсы имеет:

  • У конечного пользователя появляется Интернет, а не удалённый доступ до ряда служб корпораций типа Facebook, ВКонтакте, WhatsApp, YouTube и т.д.! Буквально появляется возможность обмениваться произвольными данными между произвольными компьютерами. Можно использовать, зачастую гораздо более эффективные, peer-to-peer протоколы, разгружая сервера. Количество перерастает в качество: все мы знаем насколько революционен был BitTorrent только для обмена файлами.
  • Исчезает NAT (всё ломающий костыль, абсолютное зло): теперь можно использовать гораздо более эффективные протоколы для различных задач. Например, SCTP для удобной гарантированной in-order передачи сообщений параллельных потоков, в противовес TCP, передающему поток байт, да ещё и с head-of-line blocking. Использовать протоколы без ненужной инкапсуляции, с лишним overhead-ом и бесполезной тратой ресурсов, например, на пересчёт контрольных сумм, как это делают с IPsec (или любыми VPN) и SCTP протоколами инкапсулированными в UDP пакетах. Использовать протоколы где не нужно разделение на порты, убирая громоздкие заголовки транспортного уровня. Это эффективно и удобно!
  • Работающий IPsec, как правило, требующий доступности хостов. Наконец-то его можно использовать не только для VPN-ов/туннелей, но и для обезопашивания хоть каждой TCP сессии по отдельности: setsockopt может делать per-socket IPsec policy, в купе с возможностью задания ожидаемых идентификаторов участников IKE соединения (sadb_ident), это с лихвой покрывает все задачи решаемые SSL/TLS-ом! Был бы IPv6 внедрён раньше, то и SSL/TLS, с очень долгой историей небезопасности, в принципе бы не появился. IPsec имеется сразу же из коробки во всех современных ОС и его трафик обрабатывается на ядерном уровне, с централизованным (один IKE/KINK/whatever демон) управлением рукопожатиями. Это очень эффективно, продуманно и удобно!
  • Не нужно заниматься выделением отдельных портов для разных демонов запускаемых на одном IP адресе — проще на отдельных IP адресах поднимать несвязанные между с собой демоны, без неудобств с отличающимися от default-ных значений портов. Каждому пользователю всё-равно выдаётся минимум /64 сеть. Это просто и удобно!
  • Глобальных префиксов так много выдаётся конечным пользователям и организациям, что просто не имеет смысла использовать site-local адреса сетей (fc::/7), рискуя иметь коллизию с какой-нибудь домашней сетью пользователя, подключающегося по VPN к сети организации (хорошо известная проблема в IPv4 мире, иногда вынуждающая переделывать адресацию домашней сети). Везде надо привыкать к тому, что стоит использовать глобальные префиксы сетей. Это очень удобно!
  • На практике, адреса сконфигурированные руками/человеками, зачастую проще запомнить чем 4 несвязанных десятичных числа, особенно если их делать мнемоническими (типа :dead:babe:): 2a02:6b8::2:242 (ya.ru), :face:b00c: в сети Facebook, 2001:4860:4860::8888 публичный DNS Google-а, 2620:0:ccc::2 (OpenDNS). А если что-то длинное автоматически сгенерированно, то человеку это на практике и не нужно запоминать/продиктовывать, так как он хоть мышкой выделит в терминале и вставит куда надо.
  • Так как все адреса выдаются иерархическим образом, то таблица маршрутизации на каждом узле/маршрутизаторе маленькая и компактная. Даже за /48, /56 или /64 сети конечных пользователей отвечают маршрутизаторы самих пользователей, которым эти префиксы делегированы. Это очень эффективно, продуманно и удобно!
  • Если умные инженеры всё же просчитались и раздача /48, /56 и подобного размера сетей каждому конечному пользователю является чересчур нерациональной и безалаберной идеей, то ничего страшного: штатно адреса для глобальных адресов сейчас раздаются только из 2000::/3 диапазона, то есть всего-лишь из 1/8 части всего возможного адресного пространства. Если это было плохим решением, то у нас ещё есть 7 попыток раздавать адреса по другим политикам. Это продуманно!
  • Killer-feature: link-local адреса. Автоматически создаваемые на каждом канале link-local адреса гарантируют наличие работающего сетевого уровня между компьютерами. Не нужно настраивать руками временные IPv4 приватные сети. Для большой организации не нужно тратить время и силы на разрезание на подсети какой-нибудь 10/8 сети, раздавая из неё адреса для маршрутизаторов, следя чтобы не пересеклось ничего. Так как IPv6 позволяет иметь много адресов на одном интерфейсе и один и тот же адрес на разных интерфейсах, то можно какой-нибудь fe80::1 на каждом интерфейсе общения с виртуальными машинами назначить и зашить намертво в образах машин как адрес шлюза. Это невероятно удобно!
  • Некоторые well-known multicast адреса позволяют легко узнать какие компьютеры вообще есть в сети (broadcast домене Ethernet-а), моментально в ad-hoc режиме их найдя и имея возможность сразу же подключиться:

    # ping6 ff02::1%igb0
    PING6(56=40+8+8 bytes) fe80::be5f:f4ff:fedd:2752%igb0 --> ff02::1%igb0
    16 bytes from fe80::be5f:f4ff:fedd:2752%igb0, icmp_seq=0 hlim=64 time=0.036 ms
    16 bytes from fe80::be5f:f4ff:fedd:98f1%igb0, icmp_seq=0 hlim=64 time=0.239 ms(DUP!)
    16 bytes from fe80::be5f:f4ff:fee6:c37e%igb0, icmp_seq=0 hlim=64 time=0.344 ms(DUP!)
    16 bytes from fe80::be5f:f4ff:fedd:9c5d%igb0, icmp_seq=0 hlim=64 time=0.479 ms(DUP!)
    
  • Killer-feature: SLAAC. Автоматическое конфигурирование адресов, буквально plug-and-play, буквально без каких-либо клиентов и серверов с базами данных для хранения состояний. Просто подключая кабель, ОС делает одну приёмо-передачу ICMPv6 пакетов, после чего является полноценным участником глобальной полностью работающей (со всеми настроенными адресами маршрутизаторов, MTU, DNS) IPv6 сети. На маршрутизаторе, с каким-нибудь rtadvd, или вообще не требуется конфигурационных файлов, или не сложнее чем одна строчка на интерфейс. Например:

    igb0:addr="2001:dead:beef::":mtu=1320:rdnss="2001:dead:beef::1":
    

  • Anycast адреса штатно поддерживаются и обрабатываются NDP протоколом, прозрачно с ними работая из коробки.
  • IPv6 заголовок существенно проще обрабатывать: нет контрольных сумм, фиксированной длины фиксированные поля, в противовес IPv4 с варьируемой длиной заголовка и пересчётом контрольной суммы на каждом hop-е. Плюс в два раза меньше полей чем в IPv4. Это эффективно и просто!
  • Flow label в IPv6 заголовке позволяет иметь состояние сессий/соединений не по (src, dst, proto, portSrc, portDst), для которого нужно распарсить и заголовок сетевого и транспортного уровней, а по (src, dst, flowLabel) которые находятся в фиксированных местах одного IPv6 заголовка. А если IP пакет фрагментирован, да так, что заголовок транспортного уровня разбит, то это задача уже не тривиальная. Flow label может быть очень эффективным!
  • Multicast рассылки NDP протокола не грузят большие сети и не прерывают работу хостов, как это делает broadcast, используемый IPv4, как минимум, для ARP и DHCP. Это эффективно!
  • Работа NDP, DHCPv6 протоколов поверх ICMPv6, поверх сетевого уровня, максимально старается разделять всё что касается сетевого и канального уровней. В идеале, NDP/ICMPv6 не нужно знать про то, поверх чего оно работает: Ethernet ли, PPP или ещё какой канал. В отличии от IPv4 мира с его ARP и DHCP, например при работе не на Ethernet, а на PPP, необходимо было встраивать в сам PPP поддержку/эмуляцию этих протоколов. В IPv6 все подобные протоколы просто работают поверх link-local адресов. Кроме того, это позволяет ещё и применять IPsec политики к ним! Это очень удобно и продуманно!
  • NDP NUD (neighbour unreachability detection) позволяет быстро определять двустороннюю (не)доступность хоста, быстро переключаясь на использование другого next hop-а или маршрутизатора, если хост перестал отвечать. Это, по сути, автоматический heartbeat хоста, в противовес просто большим timeout-ам в IPv4. Это просто и эффективно!
  • NDP RA (router advertisement) и NDP redirect пакеты сразу же содержат адреса канального уровня, а не только сетевые, не требуя совершать дополнительные round-trip-ы для NDP address resolution, как это было в IPv4 мире. Это продуманно и эффективно!

Отдельно хочется упомянуть отлично продуманный Mobile IPv6. Имея всего-лишь относительно простого демона (home agent) в домашней сети и демона на мобильном хосте (mobile agent), можно иметь полностью работающий мобильный IPv6, когда, обращаясь по домашнему адресу, всегда можно достучаться до мобильного. В отличии от Mobile IPv4, без каких-либо дополнительных требований к сети где находится мобильный агент. IP пакеты при этом просто будут эффективно (всего-лишь добавляя расширенный IPv6 заголовок) проксироваться с домашнего агента на мобильный. Кроме того, если сторонний инициатор соединения тоже поддерживает MIPv6, то он прозрачно договорится с домашним и мобильным агентами о том, что трафик он будет слать напрямую мобильному хосту, без проксирования через домашний, обеспечивая максимальную возможную эффективность (с учётом одного расширенного IPv6 заголовка) передачи. А благодаря быстрому NDP NUD, смена мобильной сети будет приводить к минимальным временным задержкам из-за обновления адреса мобильного хоста. И всё это с минимальными добавлениями в ICMPv6/NDP протоколы, введением простого расширенного IPv6 заголовка и Mobility Header.

Даёшь IPv6 и полноценный Интернет в массы!

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (357):

  1. gudvinr
    /#21334004 / +2

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


    Для обычного человека с SOHO роутером, если производитель сразу хорошо сделал, никаких проблем нет и SLAAC — это может быть и круто, всё само раздалось, у устройств в сети белый внешний адрес появился.


    Но недавно пытался настроить IPv6 на RouterOS и, несмотря на то, что провайдер поддерживает и в openwrt завелось всё сразу, микротик либо не выдаёт клиентам адреса, либо себе, либо не пускает трафик наружу через себя.
    А все материалы сводятся к тому же, что у вас написано: настройте SLAAC, это стильно, модно и молодёжно. Но при этом стек технологий вокруг IPv6 крайне сложный, и если ты не зароешься в RFC на долгие дни, то разобраться весьма проблематично.

    • Wexter
      /#21334060

      Но недавно пытался настроить IPv6 на RouterOS и, несмотря на то, что провайдер поддерживает и в openwrt завелось всё сразу, микротик либо не выдаёт клиентам адреса, либо себе, либо не пускает трафик наружу через себя.

      SLAAC на ROS настраивается в 2 клика, просто кто-то всё ещё считает что ROS для домохозяек и всё должно предельно просто настраиваться.

      • gudvinr
        /#21334230

        И всё тоже самое, с точностью до вариаций перевода пишут в ответах на форумах микротика, на реддите, на stackexchange.


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

        • Wexter
          /#21334412

          Достаточно открыть вики и осмысленно прочитать.
          SLAAC настраивается в добавлении адреса.
          Если у вас статика — вешаете /64 адрес на интерфейс и ставите advertise=yes, если получаете по DHCP-PD — вешаете адрес ::1/64 (например, так то любой какой захотите), указываете пул адресов из которого брать и так-же включаете advertise. Допом в IPv6 — ND можете покастомизировать что микрот будет отдавать в SLAAC.
          Если же вы из отряда тех кто хочет префикс отличный от /64 заставить работать с SLAAC — вам путь в RFC где определено что SLAAC должен работать только для /64.

          • edo1h
            /#21335460

            Если же вы из отряда тех кто хочет префикс отличный от /64 заставить работать с SLAAC

            ну вот у меня дома есть динамическая подсеть /64 от провайдера.
            есть wifi-сеть.
            есть проводная сеть (даже не одна на самом деле, поделены vlan'ами)
            есть сети для виртуалок.


            и какой мне толк от сети /64 провайдера, если я не могу её нарезать?!?

            • stargrave2
              /#21335516

              Нарезать можете без проблем: у меня дома и /126 сетей не одна. Да, SLAAC на меньших размерах не будет работать.

              • edo1h
                /#21335540

                Да, SLAAC на меньших размерах не будет работать.

                хорошо, и как будет выглядеть подключение к сети с телефона без SLAAC?

                • stargrave2
                  /#21335604

                  Если вам его хочется засунуть в сеть меньшего размера: руками (статика) или DHCPv6. Мне не мешало отдавать и /64 сеть SLAAC-у и одновременно нарезать её для хостов на одном и том же маршрутизаторе.

                  Только вопросы: а зачем вам её нарезать? У 99.9% пользователей не возникнет такой надобности (SLAAC удовлетворяет их). И чтобы вопросов «как нарезать» не возникало, дают рекомендации выдавать /56 или даже /48 сети конечным пользователям. Насколько видел статистику, большинство провайдеров выдавало /56 или больше.

                  • edo1h
                    /#21335794

                    не мониторю ситуацию, но по состяюнию на год назад из трёх провайдеров в моём доме ipv6 предлагал только один, у него /64

                  • Tolmy
                    /#21335814

                    Да, только вот есть явно больные на всю голову провайдеры, которые даже /64 выдавать жлобятся, а выдают /128. и когда просишь у них /56 смотрят на тебя, как на идиота. Хотя, с другой стороны, это ещё более-менее вменяемые провайдеры, совсем невменяемые говорят, что у "нас IPv6 нет и не планируется".

                  • edo1h
                    /#21335926

                    Мне не мешало отдавать и /64 сеть SLAAC-у и одновременно нарезать её для хостов на одном и том же маршрутизаторе.

                    а можно детали?

                    • Tolmy
                      /#21335972

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

                  • edo1h
                    /#21335982

                    большинство провайдеров выдавало /56 или больше

                    гугл привёл на:
                    https://version6.ru/isp


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

            • Wexter
              /#21335574

              попросите у провайдера /48, я не думаю что он разорится от этого

              • stargrave2
                /#21335618

                Полностью согласен! Именно поэтому рекомендуют давать больше чем /64. HurricaneElectric туннельный брокер например просто так даёт людям /48 префиксы, бесплатно и без проблем — так что это точно не проблема.

              • edo1h
                /#21335836

                попросите у провайдера /48, я не думаю что он разорится от этого

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

                • stargrave2
                  /#21336154

                  Мне кажется всё может зависеть буквально просто от одного человека на той стороне, как повезёт (к сожалению). Ростелеком вот с трудом, но сказал что PTR записи для статических IP он будет выдавать только юрлицам. А вот NetByNet просто одним email-ом без проблем меняет и прописывает их.

                • nlykl
                  /#21336834

                  Мелкие провайдеры могут пойти навстречу. Мне два провайдера делали статику IPv4 абсолютно бесплатно.

              • netch80
                /#21338282

                > попросите у провайдера /48, я не думаю что он разорится от этого

                «После пятнадцатого отрывания провода злобной уборщицей умоляешь провайдера перевести тебя на ppp. Провайдер добрый, посылает на [censored] только первые 82 раза, потом соглашается.» ©

          • netch80
            /#21338276

            > SLAAC настраивается в добавлении адреса.

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

            1. Провайдер выдал /56 (хороший, добрый провайдер). Как это происходит на протокольном уровне, и что надо нажать/написать у устройства, пригодного для раутера фирмочки на 20 человек.

            2. Как этот же шлюз передаст информацию о выданной сети на раутер отдела, который будет выдавать уже /64 на отдел.

            3. Что будет, если провайдер сменит этот адрес: как он пришлёт нотификацию, как она пробежится вниз до каждого конкретного компа/телефона/etc, заставляя их сменить адрес.

            4. Как эта смена адреса будет отражена в DNS, поддерживаемом этими раутерами/шлюзами.

            Упрощённый вариант — домашняя сеть, получено /56 или /64 от провайдера, точно так же раздаётся на уже одну локальную сеть (простым аппаратом с WiFi рогами ценой до 100$).

            Варианты с домашним устройством дороже 100$ или SOHO дороже 300$ не принимаются. Варианты, где оповещение вниз вплоть до каждого аппарата (компа, телефона, принтера, умного дверного замка...) не раздаётся, и он тормозит часами, прежде чем перезапросить адрес — тоже.

            Если такого варианта нет, он чудовищно дорог или требует больше, чем включить 2 галочки с понятными названиями на вебе раутера — все рассказы про SLAAC и прочие страшные слова это «в пользу бедных».

            • ivlad
              /#21338350

              Это делается за счёт prefix delegation. Иерархический PD тоже в принципе возможен, но я не уверен, что в «фирмочке на 20 человек он нужен». Такое, пожалуй, двумя кликами не настроить. Иерархические сети требуют больше усилий в настройке.


              А вот второй вариант, да, в моем роутере, полученном от провайдера настроился двумя кликами.


              Почитайте про PD. И не думайте, что эта проблема не была осознана и решена.

              • netch80
                /#21338414

                > А вот второй вариант, да, в моем роутере, полученном от провайдера настроился двумя кликами.

                Вот я и прошу назвать модель, а также параметры (какие времена он позволяет задать, в первую очередь, для router advertisement). Как клиентские терминалы на это реагирует. Как оно отражается в DNS. Что это в принципе возможно и по каким словам — я знаю. Интересует именно практика на своём опыте.

                > Почитайте про PD. И не думайте, что эта проблема не была осознана и решена.

                Читал. Осознана — по крайней мере теми, кто способен осознать — спора нет. Решение — 1) таки вопрос о точных моделях. 2) Что с DNS? Это из коробки где-то есть? Заниматься сексом по скрещиванию какого-нибудь dhcpd с dnsmasq я-то смогу, а как быть админу мелкой конторы?

                > Иерархический PD тоже в принципе возможен, но я не уверен, что в «фирмочке на 20 человек он нужен». Такое, пожалуй, двумя кликами не настроить. Иерархические сети требуют больше усилий в настройке.

                Пусть не 20, а 50. Всё равно — уровень сложности настройки?

                • ivlad
                  /#21338710

                  Вот я и прошу назвать модель

                  https://www.asus.com/Networking/RT-AC1200G-plus/specifications/


                  а также параметры (какие времена он позволяет задать, в первую очередь, для router advertisement).

                  Я поленился смотреть, что там можно настраивать. В RA прилетает 600 секунд lifetime и RDNSS.


                  Как клиентские терминалы на это реагирует.

                  Ожидаемо: настраивают префикс и DNS. В системных настройках появляются оба адреса роутера: v4 и v6. v6 появляется тот, что с глобальным скоупом.


                  2) Что с DNS? Это из коробки где-то есть? Заниматься сексом по скрещиванию какого-нибудь dhcpd с dnsmasq я-то смогу, а как быть админу мелкой конторы?

                  Я без понятия. У меня маршрутизатор не умеет динамически апдейтить DNS для локальной зоны — что для v4, что для v6. Я не в курсе, какие SOHO маршрутизаторы такое умеют.


                  Мне кажется, вы хотите скрестить ужа с ежом: сначала говорите про SOHO маршрутизаторы и минимальную настройку в два клика, а потом сразу — про Active Directory. Насколько мне известно, AD в два клика не настраивается, а требует заметной работы при установке. В компаниях на 20 и даже на 50 человек не встречается, возможно, за исключением самых редких случаев. SOHO маршрутизатор — обычно 1-2-3 VLAN, затерминированные на нём. Резолв адресов — через mdns или LLMNR, никакого внутреннего DNS.


                  Как AD DC переживают изменение префикса, я не знаю, не сталкивался.


                  Пусть не 20, а 50. Всё равно — уровень сложности настройки?

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

                  • netch80
                    /#21340948

                    > Я поленился смотреть, что там можно настраивать. В RA прилетает 600 секунд lifetime и RDNSS.

                    OK. 600 секунд это настолько много, что слово «чудовищно» недостаточно, это ещё хуже. В идеале это всё должно реагировать за полсекунды, а на смену адреса эти самые RA должны лететь не ожидая таймаута и пачкой в несколько штук для дублирования. А для надёжности корпоративного уровня оно ещё должно заглянуть в lease DB и пинать каждого, кто не переключился.

                    > Я без понятия. У меня маршрутизатор не умеет динамически апдейтить DNS для локальной зоны — что для v4, что для v6. Я не в курсе, какие SOHO маршрутизаторы такое умеют.

                    Значит, пишу: этого ещё нет ;(

                    > Мне кажется, вы хотите скрестить ужа с ежом: сначала говорите про SOHO маршрутизаторы и минимальную настройку в два клика, а потом сразу — про Active Directory.

                    Нет, это вопрос по разным уровням, от минимума до близкого к максимуму. Но AD вполне возможен и на 50 сотрудников.

                    В общем, пока с практической доступностью этих возможностей явно не плохо, а очень плохо :(

                    • ivlad
                      /#21341624

                      OK. 600 секунд это настолько много, что слово «чудовищно» недостаточно, это ещё хуже. В идеале это всё должно реагировать за полсекунды, а на смену адреса эти самые RA должны лететь не ожидая таймаута и пачкой в несколько штук для дублирования.

                      На что оно должно реагировать за полсекунды и почему? И какой протокол так уже сейчас делает?


                      Значит, пишу: этого ещё нет ;(

                      Вы всё-таки определитесь, вы про "надёжность корпоративного уровня", или про SOHO маршрутизаторы.


                      Но AD вполне возможен и на 50 сотрудников.

                      Вполне возможен и на 5. Только обычно его нет.


                      Я ещё раз повторюсь, определите задачу. Если задача про SOHO маршрутизатор, обслуживающий два VLAN и меньше сотни клиентов — это одно. Если задача про AD и сотни клиентов с дополнительными маршрутизаторами внутри сети — другое. Пока вы перескакиваете с одной позиции на другую и жалуетесь, что SOHO коробка за сотню долларов не даёт вам достаточного времени сходимости. Так в IPv4 она тоже не даёт.

                      • netch80
                        /#21341742

                        > На что оно должно реагировать за полсекунды и почему? И какой протокол так уже сейчас делает?

                        Протокол — не делает. А вот NAT — устраняет необходимость зависеть от внешних адресов в принципе.
                        Внутренняя сеть строится на site-local или ULA адресах, на границе — NAT. Проблемы известны, на некоторые я традиционно вою волком (как SIP media transport), но если выбирать, что лучше — знание внешними хакерами структуры внутренней сети или проблемы с отдельными сервисами — я выберу второе.

                        > Я ещё раз повторюсь, определите задачу. Если задача про SOHO маршрутизатор, обслуживающий два VLAN и меньше сотни клиентов — это одно. Если задача про AD и сотни клиентов с дополнительными маршрутизаторами внутри сети — другое.

                        В том и дело, что разницы здесь нет. Есть задача, универсальная на все случаи: если мы не используем постоянные внутренние адреса, а строим на внешних адресах — то имеем грабли, которые надо решать (и список этих граблей я привёл). Home или корпорация с AD — объём проблем тот же, меняются только те сетевые средства, которые надо лечить.

                        Тут, однако, надо заметить, что можно пытаться выставлять на каждый внутренний хост одновременно site-local/ULA и внешний адрес, во внутренний DNS выставлять внутренние адреса, и надеяться на маршрутизацию. Наверно, можно, но я ещё не видел dhcpd с выдачей нескольких адресов одновременно. Если это будет — можно будет обсудить грабли такого решения (но срочное оповещение при переключении таки всё равно будет полезно).

                        > Так в IPv4 она тоже не даёт.

                        В IPv4 частные адреса внутри — норма, и нет апологетов тотального отказа от них, которые на формулировки проблем начинают рассказывать, что сегодня потребности в колбасе нет.

                        • ivlad
                          /#21341826

                          но срочное оповещение при переключении таки всё равно будет полезно

                          Если у нас возникает необходимость сменить префикс при переключении, маршрутизатор рассылает старый префикс с lifetime 0 и новый с lifetime больше 0. И после этого хосты получают новые адреса, думаю, как раз за те полсекунды или меньше.


                          Вы всё-таки в традициях RU.OS.CMP задаёте не тот вопрос, на который хотите ответ услышать, а потом жалуетесь, что вам ответ не подходит.


                          Это всё и лучше есть в OpenVMS, как говорится.


                          Наверно, можно, но я ещё не видел dhcpd с выдачей нескольких адресов одновременно.

                          Не уверен, причём тут DHCP, если мы говорим про RA. IPv6 хосты могут иметь несколько адресов на интерфейсе (в том числе от разных маршрутизаторов), это им никак не мешает.


                          Home или корпорация с AD — объём проблем тот же, меняются только те сетевые средства, которые надо лечить.

                          Корпорация — это наверняка PI адреса и BGP с парой провайдеров. Тут ничего не поменялось относительно IPv4. Разница между IPv6 в Яндексе и IPv6 у меня дома существенна. И я уверен, что вы про это в курсе, но специально делаете вид, что нет.


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

                          Это что они traceroute могут сделать или адреса порезолвить? Или какое знание?

                          • netch80
                            /#21341942

                            > Если у нас возникает необходимость сменить префикс при переключении, маршрутизатор рассылает старый префикс с lifetime 0 и новый с lifetime больше 0. И после этого хосты получают новые адреса, думаю, как раз за те полсекунды или меньше.

                            Это теория или практика?
                            И как быть с возможными потерями в сети?

                            > Вы всё-таки в традициях RU.OS.CMP задаёте не тот вопрос, на который хотите ответ услышать, а потом жалуетесь, что вам ответ не подходит.

                            Я формулирую как общий вопрос, так и частные вопросы о предполагаемых наиболее типичных проблемах и методах реализации. Второе, естественно, уточняется по ходу общения. Но если собеседники отвечают только на частности (причём часто не на те вопросы, что задавались) и игнорируют общий вопрос — приходится ходить кругами.
                            RU.OS.CMP тут ни при чём, кроме того, что там тоже часто обсуждение велось из сравнения каких-то локальных абсолютов собеседников. Но там это часто была любимая система или привычный метод работы, а я таки иду от основной задачи.

                            > Не уверен, причём тут DHCP, если мы говорим про RA.

                            RA тоже устроит, если он будет уметь надёжно обновлять мировые адреса и поддерживать параллельные site-local/ULA.

                            > Корпорация — это наверняка PI адреса и BGP с парой провайдеров.

                            Хм, а почему сразу «наверняка PI»? По моим данным, это как раз далеко не типичный случай даже для крупных корпоративных сетей. Наоборот, многие отказывались именно потому, что им казалось надёжнее опираться на провайдера, даже если возникает какой-то внутренний балансинг.

                            > И я уверен, что вы про это в курсе, но специально делаете вид, что нет.

                            В курсе. «Специально» что — не признаю тотальность стремления к PI для таких целей? Верно, не признаю — потому что вижу обратное — PI таких мало.

                            > Или какое знание?

                            Какие хосты входят в какие сети (грубый пример: наверняка у безопасностников своя локалка; вот пришёл кто-то явно по профилю => всех из того же /64 более активно подозреваем, что у них есть спецдоступ, и готовим трояны для них).
                            Какие запросы ходят с одного хоста (вот этот вот ...:01:02:ff:fe:03:04 явно бухгалтер, а сосед — явно продажник).
                            И прочая и прочая. Если против фирмы начат APT, то на этом можно собрать много информации для будущих диверсий.

                            • ivlad
                              /#21347686

                              Это теория или практика?

                              RFC4861 разделы 6.3.4 и 6.3.5. Если вы скажете, что это теория потому, что кто-то может не следовать RFC, то я сразу могу ответить, что крупные игроки RFC в основном следуют, а те, кто не смог правильно реализовать, не реализуют IPv6.


                              И как быть с возможными потерями в сети?

                              Самое худшее, если клиент пропустит все RA, то оттаймаутится.


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

                              А по моим — наоборот. И что теперь?


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

                              Если они решили опираться на провайдера, они могут договориться с провайдером о статическом префиксе. Это те же компании, которые договариваются о статическом IPv4 на внешнем интерфейсе, чтобы поднимать IPSec.


                              А то вы опять смешиваете SOHO и средние и крупные компании.


                              И прочая и прочая. Если против фирмы начат APT, то на этом можно собрать много информации для будущих диверсий.

                              Сейчас большие сети так делать не рекомендуют. Делают L3 между доступом и агрегацией и выделяют /64 (или больше) на коммутатор на уровне доступа. Поэтому да, можно извне отличить восьмой этаж офиса от пятого. Эта проблема существует.

            • Wexter
              /#21338692

              1. Провайдер выдал /56 (хороший, добрый провайдер).

              Статика или DHCP-PD?
              2. Как этот же шлюз передаст информацию о выданной сети на раутер отдела, который будет выдавать уже /64 на отдел.

              DHCP-PD
              3. Что будет, если провайдер сменит этот адрес: как он пришлёт нотификацию, как она пробежится вниз до каждого конкретного компа/телефона/etc, заставляя их сменить адрес.

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

              Тут увы я бессилен, с виндовой инфраструктурой к счастью не приходилось работать. Хотя сдаётся мне что для компании получать от провайдера динамику — признак плохого тона. 99% проблем решится договорённостью с провайдером на статику.
              Варианты с домашним устройством дороже 100$ или SOHO дороже 300$ не принимаются. Варианты, где оповещение вниз вплоть до каждого аппарата (компа, телефона, принтера, умного дверного замка...) не раздаётся, и он тормозит часами, прежде чем перезапросить адрес — тоже.

              Не знаю как в в длинка/тплинках/etc, в микротике (что забавно он попадает и до 100$ и больше 300$, ибо ось одна на всех) можно настроить время делегирования префикса, опять же нужно проверить на практике, есть у меня большая уверенность что микротик разошлёт всем в сети новый префикс.

              • netch80
                /#21340966

                > DHCP-PD

                Это реально работает, что корневой DHCP сервер передаёт подчинённому, а тот — пинает уже своих листовых подчинённых?

                > Кстати интересный вопрос, надо будет проверить на досуге, но скорее всего большая часть производителей не рассчитывала на такой вариант.

                Вот как раз я слышал про фиаско поиска такой возможности. А это значит, что динамика тут не работает.

                > можно настроить время делегирования префикса

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

                И это я ещё не поднял тему пропинать всех внутри OS (что, если, как сейчас чуть менее, чем все, держат всякие websocket?)

                • ivlad
                  /#21341626

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

                  А какой протокол так делает?

    • dimaaannn
      /#21338286

      Именно так. Имел аналогичный опыт в настройке микротика, с попыткой прогнать всё это через туннельного брокера. Я совершенно не понимаю комментаторов, которые говорят что «настраивается в 2 клика», рассуждая с точки зрения обывателя

      Немного нытья, почему я выпилил нафиг IPv6 из своей небольшой сетки:
      1. Совершенно нечитабельные и не запоминаемые адреса. Зайти на удалённую машину вбивая IPv6 руками? Нет, спасибо. Продиктовать его кому-то по телефону? Селестия упаси.
      Гораздо проще настроить локальный DNS, но делать это для каждого ресурса совершенно нет желания.
      2. Непонятность принципов работы. Я использовал туннельного брокера для получения глобальной подсети, и надеялся что при небольших усилиях смогу получать доступ к определённым ресурсам внутренней сети извне.
      Однако реальность была другого мнения. Машины сами назначают себе случайные адреса, маршрутизатор раздаёт адреса, но они не работают извне, raspberry pi вообще отказалась адекватно взаимодействовать с IPv6, выдавая ошибку при попытке обновления.
      3. Общая сложность наворотов технологий. Как настроить фаерволл, шоб не накосячить? Как настроить маршрутизацию с внешними сетями? Какие это вообще даёт преимущество лично мне, как «SOHO администратору»?

      Я не пытаюсь кого то убедить что IPv6 это плохо, просто рассказываю своё видение как «не специалиста по сетевым технологиям» а как «немного шарящего в сетях чувака»

      • Wexter
        /#21338918 / +1

        Я совершенно не понимаю комментаторов, которые говорят что «настраивается в 2 клика», рассуждая с точки зрения обывателя

        Ну начнём
        1. Совершенно нечитабельные и не запоминаемые адреса. Зайти на удалённую машину вбивая IPv6 руками? Нет, спасибо. Продиктовать его кому-то по телефону? Селестия упаси.

        Ну такая себе претензия, DynDNS никто не отменял, думаю в ближайшее время появится такой функционал у большинства девайсов.
        2. Непонятность принципов работы. Я использовал туннельного брокера для получения глобальной подсети, и надеялся что при небольших усилиях смогу получать доступ к определённым ресурсам внутренней сети извне.
        Однако реальность была другого мнения. Машины сами назначают себе случайные адреса, маршрутизатор раздаёт адреса, но они не работают извне, raspberry pi вообще отказалась адекватно взаимодействовать с IPv6, выдавая ошибку при попытке обновления.

        Адреса у вас скорее всего раздались по SLAAC, при таком варианте устройство получает 2 адреса, один постоянный на основе MAC адреса (EUI-64), второй сгенерированный рандомно и сменяемый с некоторым интервалом.
        Про «не работали извне», либо у вас некорректно настроен файрвол на маршрутизаторе, либо на хосте. Либо и там и там.
        3. Общая сложность наворотов технологий. Как настроить фаерволл, шоб не накосячить?

        Да так-же как в ипв4. Разрешить ICMP и входящий трафик для ESTABLISHED/RELATED соединений. Ну и по желанию открыть полный доступ к хостам имеющим свой файрвол, либо для каждого хоста прописывать правила для портов/протоколов на роутере.
        просто рассказываю своё видение как «не специалиста по сетевым технологиям» а как «немного шарящего в сетях чувака»

        Почему-то каждый такой «не специалист, немного шарящий» пытается прикинуться хомячком, а зарится на вполне себе админские задачи, которые хомячкам не интересны и не нужны.
        Собственно говоря настройка файрвола на IPv4 и IPv6 ничем не отличается, просто у вас никогда небыло своей хотя бы /24 белой в IPv4 которая маршрутизируется глобально. Скорее всего вы всю жизнь считали что NAT это файрвол и он защищает всю вашу сеть, что в корне неверно

        • dimaaannn
          /#21340766

          Настроить банальную маршрутизацию — это НЕ админские задачи, максимум — уровень эникейщика. С IPv4 проблем в этом плане никогда не было, как и с фаерволлом для него.

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

          • Wexter
            /#21340934

            Настроить банальную маршрутизацию — это НЕ админские задачи, максимум — уровень эникейщика. С IPv4 проблем в этом плане никогда не было, как и с фаерволлом для него.

            Банальную это прописать шлюз? В таком случае естественно это не админские задачи, вот только про это я ничего и не писал, с чего вы начали переводить стрелки?
            Согласитесь, чтобы установить роутер в квартиру и сделать «шоб работало» — это уровень домохозяек, но никак не эникейщиков.

            Установить роутер и включить получение адреса по DHCP одинаково легко для домохозяек как для ipv4, так и для ipv6. Выше спрашивали про более сложные конфигурации, выходящие за пределы «домашнего» использования.

        • netch80
          /#21340980

          > Ну такая себе претензия, DynDNS никто не отменял, думаю в ближайшее время появится такой функционал у большинства девайсов.

          IPv6 — 26 лет. Новое поколение выросло. Где функциональность?

          Но DNS — это тут не ответ. Как только начинаются реальные проблемы «только где же этот кто-то и куда он мог залезть?» — начинается поиск на уровне IP адресов. И вот тут-то оно и стукнет. Запомнить среднему админу даже пару десятков IP адресов не проблема. А v6?

          > Почему-то каждый такой «не специалист, немного шарящий» пытается прикинуться хомячком, а зарится на вполне себе админские задачи, которые хомячкам не интересны и не нужны.

          Ну я админом разных уровней, вплоть до CTO провайдера, был 10 лет, так что представляю себе.
          Да, проблем не так много по их чисто количеству — длинные адреса, дублирование адресных пространств, сложность одновременной поддержки DHCPv4 и RAv6 (если кому-то нужно), дублирование в DNS (и необходимость управления логики резолвинга), шлюзы адресаций, всё назвал? Но каждая сама по себе бьёт достаточно серьёзно.

          • Wexter
            /#21341136

            IPv6 — 26 лет. Новое поколение выросло. Где функциональность?

            А кто его за последние 26 лет торопился внедрять и тестировать в массах? По вашему IPv4 на старте не имел проблем и там всё сразу было?
            Но DNS — это тут не ответ. Как только начинаются реальные проблемы «только где же этот кто-то и куда он мог залезть?» — начинается поиск на уровне IP адресов. И вот тут-то оно и стукнет. Запомнить среднему админу даже пару десятков IP адресов не проблема. А v6?

            У админа пара триллионов серверов в сети? Запомнить пару десятков адресов точно так-же просто. Если у вас проблемы с запоминанием — это не проблема протокола.
            Все проблемы что вы перечислены чисто надуманные и относятся к разряду «я привык на ipv4 и нафиг мне ваш ipv6, чего вдруг я должен что-то ещё изучать и понимать для внедрения?». Хотя там все новшества изучаются за один вечер неспешно.
            Нужно дождаться массового внедрения (хотя бы 50% мирового трафика) и поддержки у 80% производителей софта/железа, тогда уже можно будет говорить о реальных проблемах, а не об этих детских придирках.
            Лично у меня пока никаких проблем не возникает с внедрением IPv6 (кроме тугих провайдеров не желающих разбираться).

            • netch80
              /#21341242

              > А кто его за последние 26 лет торопился внедрять и тестировать в массах? По вашему IPv4 на старте не имел проблем и там всё сразу было?

              Проблема с миграцией адресов в сети по сигналу от провайдера — не требует какого-то особого «тестирования». Она понимается любым, кто хотя бы 5 минут спокойно посидит подумает над проблематикой и захочет решать осмысленно, а не затыканием дырки — и, кстати, неоднократно озвучивалась ещё в 90-е. Но ни вендоры, ни IETF оказались не заинтересованы в минимальном предвидении хотя бы на полшага вперёд.

              > Все проблемы что вы перечислены чисто надуманные

              Ни капельки. Даже проблема размера адреса это следствие известного правила «7±2»: v4 адрес ещё влезает в объём запоминаемого одной порцией, v6 — уже надо специально дробить на части и применять особые мнемотехники. Это, да, не юзерам (большинству) головная боль, это админам.
              Если вы лично от этого не страдаете — считаем, вам повезло.

              > Хотя там все новшества изучаются за один вечер неспешно.

              «Изучить новшества» да, можно за один вечер. Но от этого до реальной практики — километровая пропасть.

              > а не об этих детских придирках.

              Вот эти «детские придирки» и начали реально выстреливать на вопросе того же использования NAT.

              • Wexter
                /#21341282

                Она понимается любым, кто хотя бы 5 минут спокойно посидит подумает над проблематикой и захочет решать осмысленно, а не затыканием дырки — и, кстати, неоднократно озвучивалась ещё в 90-е. Но ни вендоры, ни IETF оказались не заинтересованы в минимальном предвидении хотя бы на полшага вперёд.

                Если вендоры и IETF не приняли это за проблему то тут два варианта
                1) Это действительно не проблема
                2) Это проблема касается крайне малого процента людей и видимо вызвана изначально неправильной структурой сети.
                Вот эти «детские придирки» и начали реально выстреливать на вопросе того же использования NAT.

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

                • netch80
                  /#21341382

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

                  Вы общаетесь с тем, кто 1) наблюдал ещё очень ранние шаги и хайп по поводу будущих перспектив IPv6, 2) в отличие от (похоже на то) большинства присутствующих, читал не только отдельные финальные RFC, но ещё и обсуждения и мотивации, а также плотно наблюдал несколько попыток радостного внедрения, с их последствиями.

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

                  > А одна из причин его появления это полный отказ от NAT

                  Верно — в детских фантазиях его первых авторов так и было бы. Но это было ещё в том интернете, где не было ни спама, ни хакеров в нынешнем количестве, и где вообще защищаться ни от чего не было нужно (а червь Морриса пробежал и был прочно забыт, как курьёз), и даже «два Bay» ещё не взрывались. Для нынешнего мира все эти наивные мечтания не годятся в принципе.

                  > Это проблема касается крайне малого процента людей

                  Верно, те, кто сейчас может наткнуться на такую проблему — вытребывают статические адреса. Но это пока не началось реально широкое распространение за пределы мобильщиков и прочих чисто-end-user групп плюс высоких корпоратов.

                  > и видимо вызвана изначально неправильной структурой сети.

                  Да-да, плавали, знаем. «У вас кривые руки» на любое отклонение от генеральной линии партии, 640KB хватит всем, а пони розовые и летают. Заранее прошу: если нет конструктивных ответов — не увеличивайте локальную энтропию.

                  • edo1h
                    /#21341704

                    Скрытый текст
                    Вы общаетесь с тем

                    я правильно понимаю, то с модератором RU.UNIX.PROG?

                    • netch80
                      /#21341756 / +1

                      Скрытый ответ
                      > модератором RU.UNIX.PROG
                      Да.
                      Только что толку, если последний активный тред в ней был 2 года назад, а предпоследний — летом 15-го.
                      Ну, могу постить в неё копии заметок из блога, поможет?

                      • edo1h
                        /#21341804

                        Скрытый текст
                        Ну, могу постить в неё копии заметок из блога, поможет?

                        нет, конечно.
                        fido мёртв, кто же с этим спорит.
                        но именно профессиональные эхи мне жалко.


                        P.S. а в FAQ заглядывал в последний раз в этом году, кажется.
                        нет желания поддерживать? или всё, что хотелось сказать, уже сказано? )

                        • netch80
                          /#21341906

                          > но именно профессиональные эхи мне жалко.

                          RU.UNIX.BSD на удивление живая. Но там ветераны :)
                          Для RU.UNIX.PROG таких не нашлось, а следующее поколение думает уже на другом уровне и другими категориями — это типа тех, кто только Linux, но с nodejs в контейнере. Им та тематика тупо не нужна.

                          > P.S. а в FAQ заглядывал в последний раз в этом году, кажется.
                          нет желания поддерживать? или всё, что хотелось сказать, уже сказано? )

                          Вопросов не задают. А сгружать весь stackoverflow в него как-то некошерно.

  2. dvserg
    /#21334050 / +1

    Неужели NAT такой весь из себя злой и ужасный? Мне кажется у него есть очень большой плюс в качестве барьера от внешних угроз внутренним сетям. Что IPv6 может предложить в этом плане? Плоская всемирная сеть хорошая идея для идеального мира. В реальности концепция приватных сетей находит большое применение.

    • stargrave2
      /#21334082

      NAT это просто сломанная связанность между хостами. С таким же успехом можно просто перерезать провода и сказать что это ещё более безопасно (и с этим тоже не поспорить). Для безопасности всю жизнь предполагалось и предполагается использовать firewall. Правило блокирующее внешние подключения к хостам локальной сети наверное в большинстве firewall-ов занимает одну строку.

      • ky0
        /#21334234

        В том-то и дело, что блокировать всё подряд — легко. А если всё-таки некоторые доступы нужны? А у нас всё подряд автоматически раздаёт себе адреса, а то и здоровенные диапазоны, пингует всё вокруг по ICMPv6, мультикастом и т.д.?

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

        • stargrave2
          /#21334260

          А чем настройка разрешения доступа на firewall будет отличаться от настройки прокидывания портов на NAT? И там и там по одной строчке правил, грубо говоря. NAT никогда не избавлял от firewall-а и необходимости его настройки.

          • stetzen
            /#21334384 / +1

            Кажется, что основной плюс NAT — то, что его «из коробки» тяжело приготовить небезопасно. Если домашняя сеть сидит за NAT, то производитель роутера не может легко и непринуждённо решить, что «а все входящие запросы мы направляем вот этой конкретной машине» и выставить её тем самым голым фронтом в интернет, проброс портов — это всё же осознанное действие, направленное на конкретные машины и конкретные порты. В то же время с v6 простое и в целом естественное решение для производителя роутера — направлять все входящие запросы по соответствующим айпи и тем самым да, создать проблемы с безопасностью. Действительно, если роутер из коробки будет иметь правило «все входящие рубить на роутере», а для внешнего доступа надо будет руками открывать конкретный порт к конкретной машине, то это ничем особо не будет отличаться от NAT с точки зрения безопасности, но у меня как-то нет уверенности, что все производители домашних роутеров будут вести себя именно так.

            • ivlad
              /#21340806

              В то же время с v6 простое и в целом естественное решение для производителя роутера — направлять все входящие запросы по соответствующим айпи и тем самым да, создать проблемы с безопасностью.

              Самое естественное решение — дропать по умолчанию все соединения извне внутрь. Собственно, так производители SOHO маршрутизаторов и поступают.

              • powerman
                /#21341654

                Ну т.е. с одной стороны декларируется (автором статьи, как минимум) "настоящий" Интернет, а с другой стороны мы прикрываемся магией conntrack, который должен определить какой UDP/ICMP/другой левый не-TCP-протокол пакет относится к мифическому "соединению", а какой нет? И для корректной работы которого хотя бы с некоторыми известными ему протоколами нужно ещё не забыть собрать и подгрузить модули-helper-ы.

                • MIKEk8
                  /#21343052

                  На мой взгляд обычному пользователю в роутере проще тыкнуть что к этим 2 компам(т.к. у каждого есть свой внешний ip) будет доступ по ftp. Чем заморачиваться, что входящие запросы на порт 20 и 21 ты переадресовывай на порт 20 и 21 на компьютер А, в запросы на порты 22 и 23 на порты 20 и 21 на комп Б, а потом ещё надо SSH прокинуть, а порт 22 ты уже заюзал, «ой ай аяяйай», а потом ещё на клиентах порты менять…

                  • netch80
                    /#21343150

                    Так conntrack, если ему не мешать, для основных протоколов это делает сам.
                    С NAT: FTP с внутренней стороны написал «шли мне данные на 192.168.23.198 порт 20» — тот поменял на 1.2.3.4 порт 61296 и исправил в проходящем FTP запросе.
                    Без NAT: хост и порт никто не менял, только дырочка проковыряна — результат тот же, входящее соединение будет принято и отраучено внутрь.
                    Проблемы начинаются, когда
                    — Какой-то свой нестандартный протокол, или даже стандартный (как SIP с SDP сессиями), но в шлюз не вложили понимание протокола
                    — Когда протокол стандартный, но шлюз его не опознал (классика — FTP, но на другом порту, не на 21)
                    — Когда таймаут на жизнь такого временного доступа (где 30 секунд, а где и полчаса) истёк, а данные всё не пошли (ну перегружен сервер, что делать)

                    Потому когда-то HTTP стал счастьем для файлового доступа, даже если это просто экспортированное в мир файловое дерево; а потом websocket для постоянного потока внутрь. IAX[2] — для VoIP, потому что нет мучений с тем, что шлюз не увидел SDP или не знает, что с ним делать. Можно ещё поискать примеров.

                    Увы, security — если не хочется всё выставлять всем в мир — всегда будет вызывать какие-то ограничения и проблемы. v4/v6, NAT/неNAT — тут уже второстепенное.

                • ivlad
                  /#21344334

                  Ну т.е. с одной стороны декларируется (автором статьи, как минимум) "настоящий" Интернет, а с другой стороны мы прикрываемся магией conntrack

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


                  Положим, есть Маша и Петя, живущие вместе и любящие он-лайн игры. Для он-лайн игры нужно открыть какой-то конкретный порт на вход, туда будет литься трафик. Как такая схема реализуется с NAT?

                  • netch80
                    /#21345154

                    > Для он-лайн игры нужно открыть какой-то конкретный порт на вход, туда будет литься трафик. Как такая схема реализуется с NAT?

                    Я пропущу про жизнь Маши и Пети вместе (непонятно, они за одним NAT или разным) и непонятку с тем, сервер онлайн игры публичный или нет, отвечу со всеми случаями.

                    1. С этого порта изнутри открывается исходящее соединение, по которому будет вливаться поток. Это работает со всеми типами NAT и именно это считается основным универсальным путём. Если сервер онлайн игры публичный, то он будет принимать все входящие и именно это будет безусловно работать.

                    Вариант имеет проблемы, если обе стороны за NAT (см. пункт 2). Но тогда и просто stateful firewall будет иметь проблемы, см. ниже.

                    2. Если NAT «конусового» типа, внешний адрес универсален (соответствует внутреннему) для всех ремотных. В этом случае клиент за NAT делает пробу с STUN-сервером, узнаёт свой внешний адрес и анонсирует его удалённой стороне. Также STUN-сервер может сказать, что NAT не конусовый, а симметричный, и эта мера не проходит. Реально конусовых NAT среди мелких — большинство, и подобный подход работает. С точки зрения секурности нет никакой разницы с тем, что вообще пришёл кто-то неизвестный, кроме того, что сверку адресов по сигнальному протоколу надо заменить сверкой содержимого. В случае обеих сторон за NAT, конусовость хотя бы одного из их NAT достаточна для установления связи.

                    3. NAT может опознать в протоколе посылку адреса порта и подменить, создав ассоциацию для входящих соединений. Для какого-то распространённого протокола, типа FTP, работает. Для онлайн игры со своим протоколом — скорее всего, нет.

                    4. Некоторые NAT имеют средства управления типа «а проковыряй мне дырочку». Фактически результат сходен с cone NAT + STUN, но со внутренним управлением. Уже не помню ключевые слова к этому средству, и вообще оно очень редкое, так что ставлю вариант в конец. (Практически, SOCKS чаще даёт то же самое, и надёжнее.)

                    По поводу первых двух вариантов — с моими 10+ годами VoIP я потоптался по всем вариантам подобных проблем и их решений ;) Самое надёжное, разумеется — это прокси на открытом «белом» адресе между сторонами. Тогда связность гарантирована. Если только одна сторона за NAT/SFW (stateful firewall) — тоже. Если обе — вот тут начинаются проблемы. Проблемы бывают двух источников:
                    1. Обе стороны за симметричным NAT, прокси нет. Шансов связаться — нет.
                    2. Обе стороны за своими SFW. Связь есть только если обе стороны одновременно могут издать исходящие пакеты. Для медиатрафика в VoIP (SIP, H.323) это норма, и вообще для UDP — не проблема. Для TCP — сильно сложнее, не все стеки разрешают одновременные встречные connect() без listen(). Для SCTP невозможно по дизайну, там всегда одна сторона изначально в listening.
                    И вот как раз пункт 2 переходит на IPv6 в полный рост: если там файрволлы с обеих сторон и их нельзя изнутри убедить «впусти мне входящие и дай свой адрес» — связи не получится.

                    • ivlad
                      /#21345696

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

                      Как это будет работать, если Маша и Петя играют одновременно и им одновременно нужен один и тот же порт?

                      • netch80
                        /#21345784

                        В каком смысле «один и тот же порт»?
                        Если вы имеете в виду соединение с разных внутренних адресов на один и тот же удалённый адрес, то NAT поставит их разным внутренним адресам разные внешние на своей границе.
                        Например, удалённый (игрового сервера) 1.2.3.4:5000, внутренние — у Маши 192.168.0.1:54230, у Пети 192.168.0.2:37665. Внешний адрес NAT шлюза — 5.6.7.8. Тогда, например, для 192.168.0.1:54230 (Маша) будет назначен внешний 5.6.7.8:1025, для 192.168.0.2:37665 (Петя) будет внешний 5.6.7.8:1026. В результате, для удалённого сервера это будут разные клиенты. Каждая такая ассоциация между внутренним и внешним адресом живёт некоторое фиксированное время от прохождения последнего пакета по ней, для UDP типичное время порядка минуты, для TCP может составлять, например, 1 час, если не прошёл явный FIN.
                        Если был вопрос только в этом, советую перечитать основы NAT, чтобы не плавать настолько в азах.
                        Если вопрос в чём-то другом — сформулируйте так, чтобы его можно было понять.

                        • ivlad
                          /#21345790

                          Нет, Маша и Петя должны получать трафик на порт 5000 одновременно.

                          • netch80
                            /#21345806

                            Повторю:

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

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

                            • ivlad
                              /#21345980

                              Повторюсь:


                              Маша и Петя, живущие вместе и любят он-лайн игры. Они хотят играть одновременно. Для он-лайн игры нужно открыть какой-то конкретный порт на вход (например, 5000), туда будет литься трафик извне. То есть, этот порт должен извне быть 5000 потому, что другие игроки будут туда отправлять трафик. Этот порт внутри тоже будет 5000 потому, что их игра слушает на этом порту.


                              Как это сделать с NAT?

                              • netch80
                                /#21346082

                                Вы всё ещё не можете чётко сформулировать задачу, но, насколько я смог расшифровать эту постановку… как говорится, вы или крестик снимите, или трусы наденьте.

                                Если у онлайн-игры сервер _снаружи_ локалки Маши и Пети, то ситуации типа «игра слушает на этом конкретном, заданном жёстко самой игрой, порту» не бывает. Клиентская сторона никогда не фиксирует у себя конкретный порт, она полагается на аллокацию операционной системой динамического номера порта, и или открывает одно соединение с этого порта, или, если ей нужны дополнительные соединения, передаёт уже полученный порт другой стороне или серверу. Времена, когда фиксировали клиентские порты, закончились вместе с первыми опытами жизни FTP в гетерогенной среде (и не только из-за NAT), то есть это не позже середины 90-х. Сейчас просто нет таких требований.

                                (Исключение: есть игры, которые для сетевого режима используют один и тот же порт для всех участников и бродкастят сообщения. Но это работает только в пределах одного L2 сегмента, не масштабируется на большее количество, и я не видел такого со времён первой халвы: кажется, последний, что такое умел, был Duke3D. А, может, ещё раньше закончилось, память уже теряет такие подробности.)

                                Если кто-то из Маши и Пети поднял у себя в локалке _сервер_ игры, то у них будет один сервер. Именно для этого сервера строится явное правило статической трансляции внутрь: все входящие соединения на порт 5000 перебрасываются на указанный внутренний адрес на порт 5000. Эта возможность присутствует даже на мелких домашних раутерах, начиная со знаменитого DI-604, и тем более на любых более продвинутых средствах. Для внутреннего получателя его IP будет внутренним, но IP другой стороны — мировым (если это не в его локалке). Исходящие пакеты от него будут транслироваться с заменой адреса отправителя на установленный настройкой внешний адрес.

                                Второй участник (предположим, что сервер у Маши — тогда это Петя) может подключаться к серверу Маши или по внутреннему адресу, или по внешнему — это на большинстве мелких раутеров тоже работает.

                                Если Маша и Петя хотят каждый у себя поднять по серверу… да, в этом случае им надо будет прописать разные порты в конфигурации статического NAT — и это ничем не будет отличаться от ситуации, например, выделенного сервера в ДЦ с одиночным IP и двумя процессами сервера игры на разных портах.

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

                                • ivlad
                                  /#21347680

                                  Нет, это не сервер. Это многопользовательские игры, в которых для уменьшения RTT клиенты могут общаться друг с другом напрямую.


                                  Такой длинный ответ вместо простого "нет".


                                  Ясно, спасибо.

                                  • netch80
                                    /#21347958 / +1

                                    > Нет, это не сервер. Это многопользовательские игры, в которых для уменьшения RTT клиенты могут общаться друг с другом напрямую.

                                    «Это» это где? В том, что вы хотели получить? Ну тогда это случай варианта 1 из моего описания, с некоторой дополнительной службой, которая оповещает участников об адресах друг друга, но дальше они взаимодействуют напрямую. И при этом ни хосты, ни порты не фиксируются, а определяются через эту службу имён.

                                    > Такой длинный ответ вместо простого «нет».

                                    Если ответ сократить до одного слова, то это «да». Но вы его не поняли.

                                    > Ясно, спасибо.

                                    Таки не за что. У меня не сработал /dev/telepathy, а вы не захотели ни объяснить, ни понять. Что ж, с таким я бессилен. Другие, надеюсь, захотят.

                                    • Tolmy
                                      /#21351168

                                      И всё таки ответ "нет".
                                      Пример. MMORPG, у которой сервер работает только как сервер авторизации, остальная связность работает как огромная mesh-сеть, где теоретически каждый может быть связан с каждым, на практике образуются ячейки связанных между собой игроков. Каждый из компов игроков — это тоже сервер по сути. И их может быть десятки тысяч. Если у кого-то сетевые проблемы, то ответ техподдержки категоричен и вынесен в FAQ — получите выделенный белый "адрес" и откройте порт XXXX на входящие соединения. Как, нас не волнует.
                                      И вот как раз с территории бывшего уже, я так понимаю, СНГ, больше всего стонов "мой провайдер белые адреса принципиально не выдает, что мне делать?" И стандартный ответ, "поздравляем, похоже вы зря потратили на игру своё бабло".

                                      • netch80
                                        /#21352052

                                        Понятно. То есть со всего огромного игрового мира нашлись какие-то шизанутые ламеры-ретрограды, которым принципиален конкретный номер порта… да, в таком случае чистая возможность получить больше адресов становится полезным.
                                        (Но, поднявшись над конкретной проблемой, это выглядит примерно такой же дикостью, как если бы они потребовали держать связь по UUCP поверх диалапа и Netware на узлах.)

      • kbkbkb
        /#21336638

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

        • stargrave2
          /#21336642

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

          • kbkbkb
            /#21336714

            Это вы назвали эту связность «сломанной». Можно назвать ее, например, «непрямой», или «усложненной». Сломанная — это если бы вообще не работала. Несимметричные маршруты, неоптимальные маршруты, низкие MTU и пр. — вы тоже назовете «сломанной связностью»?

            • stargrave2
              /#21336720

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

              • netch80
                /#21338458

                Тогда она формально симплексная, что значит — в одну сторону. Полудуплексная — это когда стороны чередуются :)

                Про ценность такой односторонности уже написал рядом.
                Но, кроме того, NAT позволяет скрыть: количество хостов внутри сети, их группировку по сетям; группировку запросов по их источникам (до хоста); связность между запросами во времени (приходят с одного хоста или с разных). Для какого-нибудь фейсбука это, безусловно, зло — он хочет отслеживать каждого юзера отдельно. Но для клиента, которому реально надо хоть немного параноить, это безусловное благо. Потому NAT будет сохраняться и для IPv6, независимо от доступности адресов — и я бы его рекомендовал всем, по этим же причинам.

                • vibornoff
                  /#21344740

                  И проблема трекинга уже сейчас решается выдачей по 2 адреса через SLAAC:
                  — «белого» для входящих соединений
                  — «серого» периодически реролящегося для исходящих соединений.

                  • netch80
                    /#21344944

                    > «серого» периодически реролящегося для исходящих соединений.

                    То есть те соединения, которым нужно долговременное существование, будут постоянно обрываться и клиентская система должна будет их пересоздавать? Вы серьёзно?

                    • none7
                      /#21345116

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

                      • netch80
                        /#21345168

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

                        Или из-за многих разных :)
                        Ответ понятен, спасибо. Как решение в принципе это может работать, да. Но откровенно выглядит как «на какое только извращение люди не пойдут, чтобы только не использовать уже проверенные годами технологии». :crash:

                      • vibornoff
                        /#21345170

                        Или, в случае v4, затрэшит табличку трансляции.

                      • Tolmy
                        /#21351200

                        Windows 10. Хром и открытые на фейсбук закладки. А если есть одновременно и IPv6, и IPv4, то винда по умолчанию всегда использует IPv6. Через сутки количество временных адресов на интерфейсе переваливает за сотню. Именно из работы этого механизма в сочетании с забавным механизмом доставки push-сообщений.
                        Вообще, противники IPv6 в чем-то правы, граблей по нем раскидано немеряно, и, хотя жить они в общем не мешают, по крайней мере обычному пользователю, которому всё равно, что там работает транспортом, но сетевикам про эти нюансы лучше знать.

                    • vibornoff
                      /#21345160

                      Подробности в RFC.
                      От себя замечу, что иметь более одного (и даже более двух) v6 ip-шника на интерфейсе — это норма. А то, что соединения постоянно обрываются, — так это вы сами придумали.

                      • netch80
                        /#21345196

                        > А то, что соединения постоянно обрываются, — так это вы сами придумали.

                        Ну вы сами сказали про 2 адреса, а не произвольное количество :) Единственный вывод. Если недоговариваете — будьте готовы к подобному. RFC почитаю на досуге, спасибо.

                        > От себя замечу, что иметь более одного (и даже более двух) v6 ip-шника на интерфейсе — это норма.

                        Для v4 это тоже уже много лет как норма. Вопрос в том, как между ними распределять роли.
                        Я так полагаю, за счёт чего-то определяется, что на один адрес соединения вешаются по умолчанию, а на второй — только явным указанием в bind()? Если да — можете не отвечать, найду в тех же RFC. Но если нет — то прямо работать не будет.

      • cartmenez
        /#21337434

        Что за смех? Миллионы домохозяек будут сидеть и править iptables? Nat в нынешних реалиях это скорее благо, нежели зло. Можно сидеть на уязвимом во все дыры тп-линке и не париться.

        NAT это просто сломанная связанность между хостами

        И да, что конкретно ломает домохозяйкам (подавляющему большинству пользователей сети)?

      • netch80
        /#21338304

        > NAT это просто сломанная связанность между хостами.

        Односторонне ограниченная, а не сломанная. Про перерезанный провод — спишем на полемический задор.

        > Для безопасности всю жизнь предполагалось и предполагается использовать firewall.

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

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

    • andreymal
      /#21334150

      NAT никак не изолирует внутреннюю сеть от подключения извне. https://habr.com/ru/post/402187/#comment_18100189


      От внешних угроз защищает фаервол.

      • Jogger
        /#21334586

        Не совсем так. Вот смотрите, есть сеть1 и сеть2, есть роутер видящий обе эти сети. Сети никак не связаны. Что в данном случае защищает сеть1 от сети2? Никаким фаерволом там не пахнет. Теперь добавляем между сетями NAT — теперь у нас есть частичная связь, например сеть1 может отправлять запросы в сеть2 и получать ответ, но входящие соединения из сети2 в сеть1 не попадут. Сеть1 всё так же частично защищена от сети2, однако никакого фаервола мы не добавляли! Что в этом случае защищает сеть1 от сети2? Да то же самое что и в первом случае — неполная связанность сетей. Да, сам по себе NAT никого не защищает, скорее наоборот, поскольку он даёт частичную связанность, а не убирает остальные связи. Но и говорить что защищает фаервол — неверно. А поскольку именно NAT даёт возможность использовать частично связанные сети, то в быту и говорят, что защищает NAT.

        • stetzen
          /#21334720

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

        • andreymal
          /#21334744

          но входящие соединения из сети2 в сеть1 не попадут.

          Попадут. Если сеть2 знает адрес конкретного компьютера из сети1 и отправит запрос к этому адресу через роутер, то роутер его прекрасно перенаправит по своим маршрутам в сеть1 без всяких там NAT, независимо от его наличия или отсутствия.


          Я пожертвовал своей сетью и перед написанием комментария провёл эксперимент, подключив к своему роутеру вместо интернет-провайдера один из компьютеров, который имитировал сеть2. И он прекрасно получал доступ к сети1 (домашней сети за роутером) в обход NAT, пока я на роутере не врубил фаервол.

          • AWSVladimir
            /#21335572

            прекрасно получал доступ к сети1 в обход NAT

            Можно по подробней с айпишниками про этот фантастический кейс?
            Как можно через NAT достучатся даже зная внутренний айпишник (например на 192.168.1.10), без проброса портов?
            Для TCP это в принципе невозможно, для UDP есть возможность, но только когда сам 192.168.1.10 полез по UDP через NAT.
            Если же 192.168.1.10 только ожидает подключения, как через NAT можно к нему достучаться?

            • edo1h
              /#21335594

              они про подключение по l2 к wan-порту роутера

            • andreymal
              /#21335598

              Как можно через NAT достучатся даже зная внутренний айпишник (например на 192.168.1.10), без проброса портов?

              Очень просто: отправить роутеру IP-пакет, в получателе указав нужный адрес (192.168.1.10). Роутер просто его отроутит по прописанным в нём маршрутам и всё. NAT'у здесь просто неоткуда взяться — он действует, только если отправлять пакеты непосредственно на адрес роутера, причём адрес принадлежащий сети2 (то есть не 192.168.1.1, а какой там интернет-провайдер выдаст роутеру)


              Для TCP это в принципе невозможно

              Это работает для любых протоколов на базе IP, в том числе для TCP. Я проверял это, открывая http-сайтик, запущенный на своём компьютере в сети1, и на компьютере из сети2 он успешно открылся в обход всех NAT.

      • a1888877
        /#21335426 / +1

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

        • andreymal
          /#21335576

          Да, но это если доверять провайдеру и не считать его внешней угрозой

      • kbkbkb
        /#21336692

        А теперь объясните, каким образом злоумышленнику попасть в подсеть WAN интерфейса роутера, чтобы обойти NAT?

        От внешних угроз защищает фаервол.
        Если немного пофилософствовать, то в контексте обсуждения глобальной адресации/маршрутизации первично то, что у внутренних хостов нет реальных IP адресов, поэтому и реализован NAT (это вторично). И безопасность — это следствие самого факта серой адресации в локальной сети, а не NAT. А кто там именно в вашей коробке занимается отбрасываением пакетом — натер, роутер, файрвол или полисер — это уже не имеет отношения к глобальной адресации/маршрутизации

        • andreymal
          /#21336708

          Вариант, что интернет-провайдер является или может стать злоумышленником, не рассматривается принципиально?

          • kbkbkb
            /#21336738

            Речь про глобальный интернет. Защищает не нат, а адресация и невозможность маршрутизации в глобальном адресном пространстве. Провайдер в данном контексте это локальная сеть и его не рассматриваем.

            • korzunin
              /#21337952

              А почему провайдера не рассматриваем? Ростелеком вон уже сегодня не брезгует рекламу в http подставлять, а что им придет в голову завтра?
              Да и кулхацкера Васю из соседнего подъезда со счетов сбрасывать наверно не стоит.
              Так что все что не под вашим контролем — потенциально враждебно.

      • netch80
        /#21338364

        > NAT никак не изолирует внутреннюю сеть от подключения извне.

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

        NAT устанавливает ассоциацию внешнего адреса внутреннему. У большинства их множество внутренних адресов больше множества внешних адресов, доступных для назначения NAT'ом — этого уже достаточно, чтобы произвольный входящий пакет не имел внутреннего адресата, если в NAT не назначена ассоциация для этого. Исключением являются те вырожденные NAT, для которых конструктивно установлено такое соответствие 1:1. Я ещё ни разу не видел такого вживую применённого, и сомневаюсь, что увижу.

        Symmetric NAT (в терминах STUN RFC), кроме того, не позволяет проникнуть на внутренний адрес запросу ни с какого удалённого адреса, кроме того, для которого этот внешний адрес был назначен. Для Cone типа такое возможно — на время жизни соответствующей ассоциации. Но Cone применяется в основном на домашних раутерах и крайне нетипичен даже для small office сегмента.

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

        > От внешних угроз защищает фаервол.

        Само правило работы NAT «впускаем только по наличию ассоциации» тут уже является таким элементов файрволла. Если в устройстве нет явных ляпов дизайна, то дополнительный файрволл для этого и не нужен.

        Наличие ingress filter при этом я считаю элементом обязательной конструкции. Проблема обсуждения по ссылке — и ваших примеров — в том, что зацикливание на возможности «а давайте отправим напрямую на внутренний адрес через хак» уводит от обсуждения принципиальной ценности NAT для большинства случаев, включая крякеров из Интернета (что на порядки типичнее взлома через соседа по локалке, который может подделать целевой MAC).

    • be52
      /#21334192

      в ipv6 можно просто фаирвол использовать, вместо «защитного» ната, запретить подключение снаружи вовнутрь
      правда это создает необходимость в механизме похожем на upnp :) а его нету
      нет в жизни счастья

      • extiander
        /#21335904

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

      • aram_pakhchanian
        /#21335928

        UPnP не привязан к IPv4, и должен работать поверх IPv6. Вы, наверное, имели ввиду конкретно NAT Traversal, но если нет NAT, то не нужен Traversal. Нужно только прописать правило firewall c правильным адресом машины, откуда пришел UPnP запрос, я думаю, маршрутизаторы этому быстро научатся, если еще не умеют.

      • vibornoff
        /#21344892

        Правильно! Даешь UPnPv6, чтобы все эти полу-умные камеры и дверные замки радостно торчали голой *опой в недобный интернет в обход стандартного правила файрвола.

    • Tolmy
      /#21335822

      NAT — не файервол.
      NAT — не файервол.
      NAT — не файервол.

      NAT — не файервол.
      Нет, NAT не обеспечивает большей безопасности по сравнению с прямым соединением.

      • dvserg
        /#21336002

        Допустим файрвол отключён. Как в ipv4 при включённом NAT осуществить сканирование хвостов в локальной сети за ним из вне?

        • Tolmy
          /#21336024

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

          • dvserg
            /#21336120

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

            • Tolmy
              /#21337042

              Я, находясь во внешней по отношении к вашему роутеру сети, шлю ему пакеты с src своим, dst — перебираю 192.168.0.0/16, 10.0.0.0/8 и 172.16.0.0/12
              Ваш роутер совершенно честно передает пакеты внутрь вашей сети, он же не файервол, правда? Внутреннее устройство отвечает на мои запросы и через роутер (он же не файрвол, да?) отправляет их во внешнюю сеть. Всё, мне доступны все ваши внутренние ресурсы. Как я это делаю? Да как угодно. Ломаю комп ваших соседей и маршрутизатор вашего провайдера. Но в большинстве домосетей всё гораздо проще, фомкой открываю ящик с коммутатором у вас подъезде и просто включаюсь к вам в разрыв. Или рву кабель, если он проложен по стенке в коридоре. Да у меня просто уйма разных методик, как это сделать.

              • sergey-b
                /#21338032

                Итак, чтобы не взломать, а просто хотя бы найти хост за NAT-ом, нужно что-то одно из:


                1. Взломать другой хост за NAT-ом.
                2. Пробраться незамеченным в помещение, соединенное кабелем с атакуемой сетью, со специальным инструментом.
                3. Взломать маршрутизатор интернет-провайдера.

                Это достаточно высокий уровень безопасности. Меня такой вполне устраивает.

                • Tolmy
                  /#21339248

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

                  • kbkbkb
                    /#21339558 / +1

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

                  • zurapa
                    /#21354624

                    Хотел бы я посмотреть на твою домашнюю сеть. У меня есть подозрения, что кто-то здесь не до конца честен.

          • powerman
            /#21336146 / +1

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

            • stargrave2
              /#21336160 / -1

              Ну это уже вопрос простейшей образованности. Про брэндмауеры в Windows регулярно все говорят в статьях/лекциях на темы простейшей безопасности при использовании Интернета.

              • powerman
                /#21336340 / +4

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


                Я считаю, что лично у меня эта "простейшая образованность" имеется: я не сетевой инженер, но я разработчик со стажем в 30+ лет и админю линух немногим меньше (с 1994), когда-то даже сделал собственный дистрибутив и поддерживал его несколько лет, сейчас на Gentoo. У меня дома кучка VLAN-ов, VPN-ов, два ISP — порядка 10-20 сетевых интерфейсов не считая докерных. И достаточно сложные правила iptables, чтобы всё это работало, и работало безопасно. Как по-вашему, тянет это на "простейшую образованность"?


                Так вот. Лично я к IPv6 присматриваюсь очень давно. Несколько раз пытался погрузиться в него всерьёз. Но каждый раз это заканчивалось тем, что моя "простейшая образованность" и серьёзное отношение к безопасности домашней сети (и сетей проектов, которые я в той или иной мере админил), приводили к простому выводу: НАФИГ этот IPv6. Причин для этого несколько:


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

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


                Лично я в принципе включил в ядре поддержку IPv6 буквально месяц-два назад (выяснилось, что без этого у телеграма не работают звонки), и при этом тут же выключил её через sysctl. Да, я понимаю, что рано или поздно, скорее всего, мне придётся включить и настроить IPv6. Может быть. Поэтому и интересуюсь статьями вроде этой. Но пока что настройка IPv6 не даст мне ничего, кроме проблем, и ни одной причины этим заниматься я пока не вижу.

                • stargrave2
                  /#21336364

                  Замечание про простейшую образованность касалось только того, что пользователь сам дурак если не помнит и не заботится о правилах firewall-а. Это как винить кого угодно в том, что вылетел из окна автомобиля при столкновении — пристёгиваться надо всегда.

                • stargrave2
                  /#21336376

                  Снова повторюсь, прочитав полностью ваш комментарий: простейшая образованность касалось только того, что я считаю что человек обязан самостоятельно думать о безопасности своей: ремень безопасности, нескользящие ботинки (а не надежда что асфальт замой будет чист), презервативы, firewall-ы.

                  Работая с IPv4 и IPv6 я наоборот увидел что с IPv6 значительно проще работать, да и в самом протоколе его link-local-ы и прочие полезности очень упрощают жизнь. Да даже просто банальное огромное количество адресов — очень удобно, не нужно ютиться. Но да, соглашусь что если это в купе с IPv4 делается (dual stack), то это увеличивает повернхность атаки и теперь нужно буквально с двумя стэками работать сетевыми. Но так всегда: переходный период, когда лошади и конные повозки существуют совместно с автомобилями, означает что какое-то время будет сложнее, чем оставаться на лошадях или жить сразу полностью с автомобилями.

                  • powerman
                    /#21336518 / +1

                    Так и я о том же. Моей образованности как раз хватило, чтобы понять, что IPv6 мне пока лучше всего выключить вообще. Именно потому, что я примерно представляю себе сложность настройки IPv6 чтобы получить эквивалент моим текущим настройкам для IPv4, и понимаю, что в конечном итоге потратив на это недели две всё, что я получу взамен — ухудшение безопасности за счёт увеличения поверхности атаки, и всё. Никаких "плюшек" от IPv6 я не получу, просто потому, что у меня нет потребности открывать доступ снаружи в свою локалку, нет потребности увеличивать связность между текущими сетями, нет даже потребности (пока) подключаться к IPv6-only сайтам.


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

                    • stargrave2
                      /#21336548

                      К вашей образованности у меня претензий нет и я уверен у меня есть чему у вас поучиться. Просто аргумент о том, что пользователям навредят потому что они не включают firewall — не серьёзный аргумент (для меня).

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

                      Большинству пользователей я уверен что достаточно иметь firewall разрешающий исходящие соединения, запрещающий входящие (ну плюс ICMPv6 и другие мелочи). Это можно производителям ОС и делать как preset, мне кажется, ибо он удовлетворит 99.(9)% людей, как удовлетворяет NAT без firewall.

                      • powerman
                        /#21336574

                        Да, наверняка можно сделать такой preset. Проблема в том, что сначала 20 лет провайдерам было сложно/дорого поменять своё оборудование, а теперь прикиньте, сколько лет займёт поменять домашние роутеры всех пользователей по всему миру — потому что в текущих роутерах таких preset-ов нет (впрочем, тут я могу ошибаться, но скорее всего — нет, либо те, что есть, сделаны чисто формально и не выдерживают никакой критики — просто потому, что производители никогда не заботятся о таких вещах пока их конкретно не прижмут).

                        • stargrave2
                          /#21336588

                          Соглашусь что домашние маршрутизаторы не выдерживают никакой критики в вопросах безопасности. Но я имел в виду firewall на конечных устройствах (компьютер с Windows/GNU/BSD/whatever, iOS+Android).

              • sergey-b
                /#21336918 / +1

                Если под брандмауэром Windows вы имеете в виду поделие, которое управляется при помощи wf.msc, то я вас уверяю, что оно не работает даже для IPv4. Чтобы просто браузер поставить, нужно включать в нем правило вида Разрешить любой трафик любой программе на любой адрес, иначе ничего не скачается.

            • dvserg
              /#21336182

              Вы поняли мои мысли. Я уверен, что приватная (локальная) сеть должна существовать, и должен быть механизм сохранения данной приватности. С другой стороны демоны локальной сети должны в ней и оставаться. Думается с развитием применения ipv6 очень сильно изменится подход к настройке файрволов

            • Tolmy
              /#21337046

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

              • powerman
                /#21337056 / +1

                Может кто-то так и делает, но у очень многих сейчас дома намного больше одного устройства — помимо ноута есть умные телевизоры, телефоны, планшеты, нередко второй компьютер… так что чаще всего этот кабель воткнут в WiFi роутер (нередко предоставленный и настроенный провайдером).

                • Tolmy
                  /#21337066

                  У меня сын некоторое время работал в саппорте интернет-провайдера, у него совсем другие сведения. Умные телевизоры, планшеты, два компьютера…
                  Вы очень преувеличиваете средний уровень обычного домашнего пользователя.
                  Больше двух третей абонентов обычных домосетей — обычные одиночные компы или нотбуки. И да, огромное количество пользователей даже не догадываются о том, что через WiFi роутер можно подключить несколько потребителей интернета к одному кабелю. Из статистики моего сына одним из самых популярных вопросов пользователей является "у меня уже есть ваш кабель, сколько стоит провести ещё один такой? А разветвители для интернета бывают?"
                  А ещё дешевые тарифные планы у мобильных операторов сделали ненужными подключения по WiFi для смартфонов. А зачем?
                  И ещё один аргумент. Вы видели, как выглядит радиоэфир на частоте 2.4ГГц в центре микрорайона из пяти 30-этажных жилых домов? И как оно "надежно" после этого работает? Обычный пользователь, поигравшись пару недель в "танчики" по вайфаю и сломав вокруг все ломающиеся предметы, звонит в техподдержку и рассерженно орет "ваш интернет нихрена не работает!", и, получив совет от саппорта попробовать включить кабель в порт компа напрямую, обнаруживает, что интернет таки стабильно работает, после чего исполняется чувства праведного негодования по поводу мошенников, которые ему этот вайфай предлагали.

                  • edo1h
                    /#21337330

                    У меня сын некоторое время работал в саппорте интернет-провайдера, у него совсем другие сведения

                    Вы видели, как выглядит радиоэфир на частоте 2.4ГГц в центре микрорайона из пяти 30-этажных жилых домов?

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

                    • Ankoroid
                      /#21337696

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

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

                      • nidalee
                        /#21344532

                        Провайдеры впаривают роутеры с wifi, настраивают, к примеру, ноутбук — и все.
                        Ну так и при чем здесь тогда «многие просто включают кабель от провайдера в свой нотбук», если этот самый ноутбук подключен к сети провайдера через его же роутер с NAT? Мне кажется, что сейчас подключить Интернет без роутера провайдера — квест, который «большинство домашних пользователей» не пройдет.
                        Лично я вот понятия не имею, как подключить GPON МГТС без роутера этого самого МГТС. В последний раз, когда читал — вроде, левые устройства они не дают подключать. Но это не точно.

                        • none7
                          /#21345392

                          Это совершенно точно. GPON это не стандартизированная технология и если производитель не сказал, что данная конкретная модель ONT совместима с данной конкретной головной станцией. То стоит предполагать, что это не так и она сломает связь всему сегменту. Так же в их ONT прошит индивидуальный ключ авторизации и они его Вам естественно не дадут.

                    • Tolmy
                      /#21338834

                      Не противоречу. Просто когда в зоне досягаемости любого устройства 3000 квартир, даже 25% пользующихся вайфаем — это просто офигительно много. А 5 домов стоящих напротив друг друга по кругу так, что можно прочитать название компании на пакете молока, которые стоит на столе в доме напротив, похоже позволяют на переотражении от соседних домах видеть всех. Вот абсолютно всех.

                      • edo1h
                        /#21346530

                        ну это вы крайний случай таки рассматриваете.
                        в обычной отдельностоящей девятиэтажке увидеть 20 сетей ­— обычное дело. и в пятиэтажке 10 тоже. из чего я делаю вывод, что почти у всех, у кого подключен интернет, есть wifi-роутер (неудивительно, провайдеры сегодня предлагают поставить свой роутер пратически бесплатно)

                        • Tolmy
                          /#21351240

                          Очевидно у меня в округе какие-то другие провайдеры. Которые выдают просто шнурок Ethernet в квартиру. А роутер у них стоит… ну в Ашане он ровно столько же стоит. Не могу сказать "дорого", но и покупать его будет только тот, кто точно знает, зачем он ему нужен, и почему ему не нужны для других целей эти $25.

                          • edo1h
                            /#21351344

                            Очевидно у меня в округе какие-то другие провайдеры. Которые выдают просто шнурок Ethernet в квартиру

                            очевидно

                            • Tolmy
                              /#21351386

                              Везет. Вот реально завидую. Аренда за 10руб. в месяц. Я бы тоже взял бы не задумываясь. У моего текущего провайдера есть IPv6 прямо из шнурка. С одной сетью /64 и /48 по запросу. Собственно, из-за них я к нему и перешел. Но вот аренды оборудования — вообще никакой.

                              • edo1h
                                /#21351438

                                странно, у нас, кажется, все провайдеры предоставляют роутер в аренду.
                                если смотреть на крупных (покрывающих весь город), то 2 из 3 готовы за дать роутер 10р в месяц.

                            • alliumnsk
                              /#21354762

                              Я вот недавно у своего провайдера узнавал. Вроде бы как цена аренды рутера 1 руб/мес. Но на самом дешевом тарифном плане (моем) такой опции нет. Чтобы арендовать рутер, мне пришлось бы перейти на тарифный план с такой же скоростью, но на 100 рублей абонплаты дороже. Т.е. получается что цена аренды составила бы 101 рубль, а не 1

            • ivlad
              /#21337474

              Большинство домашних пользователей как получали маршрутизатор от провайдера с управлением через TR-069, так и будут получать.

            • Tolmy
              /#21339262

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

        • Dimasmir0
          /#21338366

          Попробую описать текстом. Представьте, что мы с вами в одной провайдерской сети 10.10.10.0/24. Вам провайдер выдал адрес 10.10.10.2, мне 10.10.10.3.
          За вашим роутером находится ваша домашняя сеть 192.168.0.0/24.
          На своей стороне я прописываю маршрут в сеть 192.168.0.0/24 через 10.10.10.2. Если у вас отключен фаерволл, то я смогу обратиться к хостам внутри вашей домашней сети.

          • netch80
            /#21338438

            Итого, случай опасности при «файрволл отключён» сводится к опасности только в особой конфигурации, в которой:

            1. WAN стороны жертвы и атакующего находятся в одном broadcast-сегменте формата «типичный Ethernet». Не выполняется в случае хакера из чуть более дальнего интернета.

            2. Это именно broadcast-сегмент с прямым бесконтрольным взаимодействием между сторонами. Не выполняется уже, например, на DOCSIS-сетях, где головные станции пропускают трафик через свой доступ и раутинг, и прямое взаимодействие между клиентами сегмента по их MAC невозможно. Кроме того, некоторые свичи позволяют организовать то же на Ethernet. Не выполняется при подключении каждого клиента персональным VLAN'ом.

            Ну да, формально можно засчитать один гол за счёт такого эффекта. Но:
            1) Практическая ценность его только в весьма частных условиях
            2) Простейший ingress filtering на входе его останавливает, и надо быть совсем зелёным админом, чтобы не поставить такое правило.

            Более того, формально, поскольку пакеты проходят в обход NAT, проблема тут не в NAT, а в раутере сбоку от него;) а может, его и нет? NAT ведь не означает раутинг вне NAT механизмов. Нет, что-то гол сомнительный :)

            А ещё варианты будут?

  3. Jogger
    /#21334156

    Да, возможностей больше. Но ведь палка о двух концах — в IPv6 гораздо труднее разобраться, особенно человеку, для которого администрирование сетей — не профессиональная деятельность. Даже в IPv4 хватает нетривиальных вещей, а в IPv6 их на порядок больше. Поэтому зачастую и делается выбор в пользу «вот оно работает и более-менее понятно» а не «надо потратить годик на обучение, зато потом я смогу настроить IPv6 и иметь кучу возможностей, из которых я дай бог 1% использую».

    • ivlad
      /#21338386

      Когда такое пишут, мне интересно становится, какой именно аспект работы IPv6 делает его «гораздо» более сложным. Вот у вас лично — понимание каких принципов работы IPv6 вызвало сложности?

  4. artemlight
    /#21334190 / +1

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

    • stargrave2
      /#21334210

      Не IPv6, а NDP и подобного уровня протоколы. Это отмечено в абзаце про требования, которые можно назвать и недостатками.

  5. PAE
    /#21334208

    Ещё лет 7 назад помню, как один друг, занятый сетевыми технологиями в академической и, одновременно, провайдерской среде утверждал, что переход на IPv6 — дело решённое и через пять лет все будут относиться к нему как к основному, забыв "старый" IPv4 как страшный сон.


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


    Абсолютное и подавляющее большинство пользуется интернетом для потребления контента или для решения конкретной задачи, когда "удобно" — это браузер, клиент или API, "красиво и эффективно" на сетевом уровне — увы, нет, это попросту невостребовано.


    Бизнес прекрасно понимает, что решить "костылями" и NAT — в разы дешевле и быстрее, чем переводить software/hardware на IPv6, поэтому и поныне IPv4 остаётся абсолютно доминирующим, а рост IPv6 трафика в основном чисто техническая заслуга отдельных контент-сервисов.


    Рискну высказать непопулярное мнение, но поймите меня корректно:


    • Я никоим образом не против IPv6, это отличная концепция и, если она действительно станет новым промышленным стандартом — то это отлично, рано или поздно IPv4 придётся менять, обновлять или заменять целиком — это бесспорно;
    • Однако, настройка и вообще "запоминание" IPv6 адресов и сетей — это боль;
    • Заниматься сменой и/или перенастройкой оборудования — это боль, потому что "и сейчас всё работает", пусть и не через красивые технологии;
    • Большинство софта, железа и в целом решений уже согасилось со всеми этими костылями и слоями абстраций;
    • Пока не возникнет выгодный, коммерчески эффективный продукт, требующий IPv6 — он будет минорным, потому что ОК, Ютуб и картинки с котами работают и сейчас, что требуется большинству.

    А что про NAT и абстракции — контейнеризация и бурное развитие SDN — это всё позволяет не обращать внимание на IPv6 вообще, для связности с "внешним миром" достаточно будет и одного адреса.

    • hjornson
      /#21334466

      Пока не возникнет выгодный, коммерчески эффективный продукт, требующий IPv6 — он будет минорным, потому что ОК, Ютуб и картинки с котами работают и сейчас, что требуется большинству.


      Ага. При этом как раз то что упоминается в статье как достоинство
      У конечного пользователя появляется Интернет, а не удалённый доступ до ряда служб корпораций типа Facebook, ВКонтакте, WhatsApp, YouTube и т.д.!
      — оно как раз этим самым службам корпораций нафиг и не сдалось. Идеал корпораций — чтобы пользователь фб не знал ничего кроме фб и за пределы его экосистемы носу не казал, а для этого v4 за глаза и зауши достаточно.

      • ivlad
        /#21337532

        оно как раз этим самым службам корпораций нафиг и не сдалось

        но почему же тогда эти самые корпорации так пропагандируют IPv6? Почему и у Google, и у Facebook сервисы отвечают по IPv6?

        • powerman
          /#21338662

          Скорее всего потому, что трекать юзера надёжно по уникальному IPv6 (а то и по всей /64, чтобы трекать все его девайсы как единое целое), без всяких кук — мечта для таких корпораций.

          • Tolmy
            /#21338846

            Как раз RFC4941, который Privacy Extensions for Stateless Address Autoconfiguration in IPv6, позволяет каждому устройству в IPv6 сети выбирать любой адрес из 4 миллиардов и делать это в любой момент по своему разумению. Windows 10, как самая популярная пользовательская ОС, умеет это делать из коробки. И делает это по умолчанию. Так что трекинг по IPv6 — плохая идея. Гораздо хуже, чем трекинг по адресу IPv4.

            • powerman
              /#21339346

              Вы в своём ответе проигнорировали эту часть сознательно?


              а то и по всей /64, чтобы трекать все его девайсы как единое целое

              • Tolmy
                /#21339394

                Это же IPv6, здесь нет бродкастов. Вообще нет. Нельзя обратиться к /64 как к единому целому. Нет никаких признаков внутри /64, одно там внутри устройство, или 4 миллиарда. Ну вот есть у меня дома /64 на всех домашних (пять компов, пять телефонов, два телевизора и планшет) Что трекать? Какой смысл в таком трекинге? Мне от 22 до 61 года, с полом я не определилось, иногда мужской, иногда женский, меня интересуют игры, гитары, электроника, красивые шмотки, подводное плавание, IT, кулинарные рецепты и схема разборки двигателя Skoda Octavia. Угу, вот трекинг по /64

                • powerman
                  /#21339556 / +1

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

          • ivlad
            /#21340252

            Так что сейчас — один внешний IP, что в IPv6 — общий префикс, какая разница. Гуглу сложно отличить телефон от десктопа? Несложно.


            И кроме того, зачем тогда они строят IPv6-only датацентры?

        • none7
          /#21338826

          Потому, что альтернатива CG-NAT, а значит меньше информации о пользователе. Представьте, что пользователь вошёл в интернет через открытую Wi-Fi точку. Гугл точно узнает где она находится, благодаря гугломобилям. А если она будет за CG-NAT, то он сможет определить в лучшем случае город. К тому же IPv6 продвигают гики, а таковых у IT-компаний полно.

          • Tolmy
            /#21339220 / +1

            CG-NAT — крайне плохая альтернатива. Достаточно одного спамера в сети, чтобы заблокировали всех, кто за этим NAT-ом сидит. Под спамером я понимаю не только и даже не столько обычного спамера по SMTP протоколу. Просто неимоверное количество сервисов блокирует доступ на уровне IP. И мне совсем не улыбается лишиться доступа к своим любимым фоточкам котиков, потому что в соседнем доме мамкин кулхацер решил развлечься.

          • ivlad
            /#21340270

            Представьте, что пользователь вошёл в интернет через открытую Wi-Fi точку.

            По-моему, сейчас таких не существует. Везде captive какой-нибудь. Но, даже, положим, андроид до этого подключился к этой точке и гугл знает, что этот внешний IP тогда соответствовал этим координатам. Дальше вариантов два:


            1. этот префикс статический, тогда гугл будет знать местоположение этой точки — аналогично тому, как это происходит в ситуации со статическим IPv4.
            2. этот префикс динамический, тогда гугл будет знать местоположение этой точки в течение суток точно и с точностью, скажем, до города, — навсегда. Это аналогично тому, что происходит с динамическим IPv4 или с GCNAT.

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

            • none7
              /#21340372

              Для чего в IPv6 динамическая выдача адресов? Кто то очень любит таблицы маршрутизации перестраивать? А если провайдер принудительно сбрасывает сессию ради изменения адреса, то бежать от него, срочно!

              • ivlad
                /#21340414

                А если провайдер принудительно сбрасывает сессию ради изменения адреса, то бежать от него, срочно!

                То есть, IPv4 вы всё-таки хотите себе неизменный, но неизменный IPv6 префикс вас пугает?

                • none7
                  /#21340472

                  Динамические IPv4 появились во времена Dial-Up, в те времена не было смысла иметь больше адресов, чем телефонных линий. Тогда возникла и услуга. Потом наследники PPP начали переходить на более быстрые технологии оставив биллинг как есть, то есть выдавая произвольный адрес на сессию. Потом пришёл ростелеком и сказал, что из за вечно включенных роутеров не рвущих сессию вообще не покупают услугу. Давайте рвать сессию каждую ночь, срывая все соединения.
                  Динамическая адресация ломает правила ipsec, а значит и Mobile IPv6. Будет неприятно если Ваш смартфон автоматически настроивший Mobile IPv6 адрес через домашний Wi-Fi, в полночь потеряет с ним связь. И сломает подключение в совершенно другой сети.

                  • stargrave2
                    /#21340488

                    Вы не правы касательно MIPv6. Точнее это зависит от реализации. В MIPv6 и при проксировании трафика через home agent и при прямой поссылки трафика с corresponding node на mobile agent, добавляется дополнительный IPv6 заголовок, говорящий что это как-бы адресовано home-of-address, а не care-of-address напрямую. При этом, скорее всего, будет использовать транспортный режим (host-to-host же). Корректная IPsec реализация должна учесть дополнительный IPv6 заголовок, превратив его в пакет как-будто с destination-ом равным HoA, а не CoA и поэтому для правил IPsec ничего не будет меняться при перемещении ноды. Так что тут никаких проблем не должно быть.

                    • stargrave2
                      /#21340490

                      Да, собственно, и с туннельным проблем нет, так как на концах туннеля будет HoA адрес, а не CoA.

                    • none7
                      /#21340538

                      Речь о том, что адрес и подсеть домашнего роутера периодически меняется. Как отреагируют удалённые хосты при создании нового соединения, если мобильный узел не сможет принять ответ на home-of-address? Мобильный узел ведь даже не в курсе, что его соединение с роутером отвалилось. И не будет в курсе пока не попытается сменить сеть.

                      • stargrave2
                        /#21340568

                        SLAAC-ом (RA пакетом) выдаётся lifetime. Адрес штатно может меняться, как и префикс — всё так. Но постоянно работает NDP NUD чтобы понимать живность маршрутизатора. При смене префикса, для NDP есть особый «мобильный» режим работы, при котором мобильная нода очень часто опрашивает RA о его параметрах, чтобы минимизировать время простоя при смене адреса. Он быстро оповестит corresponding ноду о смене, снова произойдёт binding на новый адрес. Это штатно заложено всё в MIPv6. Повторюсь: в IPv6 работает NDP NUD (neighbour unreachability detection) как-раз чтобы быстро понимать отвалились ли мы и предпринять действия. При смене адреса мобильный агент сразу же оповестит домашнего.

                      • Tolmy
                        /#21351278

                        В IPv6 процесс смены адреса по RA несколько отличается от IPv4.
                        Можно жить некоторое время со старым и новым адресом одновременно, причем старый будет использоваться ровно столько, сколько на нем будут открыты соединения. Новые — будут использовать новый полученный адрес.

                        • edo1h
                          /#21351368

                          В IPv6 процесс смены адреса по RA несколько отличается от IPv4.
                          Можно жить некоторое время со старым и новым адресом одновременно, причем старый будет использоваться ровно столько, сколько на нем будут открыты соединения.

                          то есть роутер отслеживает, что старый адрес ещё используется, и только потом удаляет запись в таблице маршрутизации?

                          • Tolmy
                            /#21351406

                            Отслеживает, что выдавал этот адрес, и тестирует, что он ещё жив. По NDP NUD. Но на самом деле это уже костыль над SLAAC. Сначала мы делаем stateless протокол, а потом костылями подпираем то, что от него отваливается. IPv6 он такой, да. Хотя, DHCP же вроде тоже есть, так что можно сделать один в один, как в IPv4.

                  • ivlad
                    /#21340550

                    ok.


                    У вас был тезис, что статический префикс в IPv6 улучшает трекинг пользователя. По моему пониманию, это принципиально не отличается от статического IP. Дискуссия о том, кто и почему стал менять адреса клиентов, если честно, мне не интересна и к IPv6, по-моему, не относится.

    • Tolmy
      /#21335944

      Пока не возникнет выгодный, коммерчески эффективный продукт, требующий IPv6 — он будет минорным, потому что ОК, Ютуб и картинки с котами работают и сейчас, что требуется большинству.

      Уже сейчас есть, к примеру, VPS IPv6 only c привлекательными скидками. Хочешь IPv4 адрес — добавь $5 в месяц к стоимости. Очень даже стимулирует.

    • aram_pakhchanian
      /#21336070

      У нас в Армении все крупные провайдеры домашних сетей уже дают IPv6 адреса, включая местную дочку Ростелекома.

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

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

    • Ankoroid
      /#21337724

      Бизнес прекрасно понимает, что решить «костылями» и NAT — в разы дешевле и быстрее, чем переводить software/hardware на IPv6, поэтому и поныне IPv4 остаётся абсолютно доминирующим, а рост IPv6 трафика в основном чисто техническая заслуга отдельных контент-сервисов.

      Дешевле как раз без NAT — у сотовых CGNAT требует немалых инвестиций, к примеру.
      Если происходит внедрение, как, например, у МТС — то дальше все работает хорошо и стабильно, абоненты даже не знают, что у них ipv6.

      В целом сейчас доля ipv6 трафика — 30% (для тех, кто перешел на ipv6).
      Странно, почему habr не переедет на ipv6 :)

    • JayK
      /#21340964

      А теперь представим что все провайдеры в рф раздали клиентам в6 адреса, и обеспечили прозрачную маршрутизацию. Роскомнадзору вы что делать при этом прикажете? Как быть? Вы модуль «ревизор» видали? Тама столько памяти нет сколько этих адресов)))

      • ne_kotin
        /#21341520

        Роскомнадзору вы что делать при этом прикажете? Как быть? Вы модуль «ревизор» видали? Тама столько памяти нет сколько этих адресов)))

        Дак пусть едят пирожные естественным образом погибают.

        • JayK
          /#21341914

          Угу, ипв6 в рф не будет потому что черные ящики сорм в его не умеют, а даже если научатся то для провайдеров поменять их сразу все совершенно неподъемно, учитывая ОЧЕНЬ специфическое ценообразование.

          • ne_kotin
            /#21342174

            То есть реестр блокировок по v6 адресам есть, а вот ящики его еще не умеют. Удивительно.
            З.Ы. У меня, кстати, в России v6 есть. И он будет, просто до какого-то времени будут закрывать глаза на то, что v6 не заблокировать качественно. Ну не умеет железо. Яровая вон тоже три года хотела трафик хранить. До того как выяснилось, что это требует от мирового производства HDD только на Россию и работать.

            • edo1h
              /#21342214

              ящики сорм — это одно, реестр блокировок — другое.


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


              P.S. сейчас проверил rutracker.org через ipv6 с "правильным" dns­ — заблокирован, как и ожидалось

              • Sugrob
                /#21343280

                А вы по http или по https пробовали?
                В случае DPI необходимо использовать https

                wget -6 -O https.html https://rutracker.org
                wget -6 -O http.html http://rutracker.org
                ls -lh *.html
                3,5K   http.html
                165K  https.html

                Как видно из размера по http приходит заглушка от провайдера.

                • edo1h
                  /#21346618

                  $ curl https://rutracker.org --resolve rutracker.org:80:[2a03:42e0::214]
                  curl: (7) Failed to connect to rutracker.org port 443: В соединении отказано

            • Ankoroid
              /#21342224

              Умеют, к сожалению :( У Ростелекома даже используют.

            • JayK
              /#21342738

              roskomsvoboda.org/41214

              Умеют только самые новые и самые дорогие. Которые надо КУПИТЬ ЗА СВОИ ДЕНЬГИ, ростелеком купит, мелкий провайдер из задрищенска…

              В 18 году модуль ревизор точно не умел проверять в6 адреса, ну и сама идея вести реестр запрещенных в6 аресов выглядит настолько идиотской, что проще отказаться от в6

              • none7
                /#21345440

                Так они же и подсетями банят. Будут по умолчанию добавлять всю /64. В особых случаях, весь PI-блок.

  6. happy-cat
    /#21334452

    Все это красиво на бумаге — но движение начнется когда домашние провайдеры а-ля МГТС с его gpon (и это в Москве! я про регионы умолчу..) соизволят раздавать ipv6 — а пока поддержки нет то можно все благополучно спустить на тормозах...

    • Extravert34
      /#21337770

      МГТС как раз раздаёт. Динамический правда, и только /64, но всё же раздаёт.
      https://version6.ru/isp/mgts

      • happy-cat
        /#21338040

        Не выдает, я общался с ТП неделю назад, мне сказали что однозначно НЕТ.
        PS даже если бы и выдавали — у меня платный статичный IPV4 — и по вашей же ссылке сказано что они вместе не уживаются — так что дважды нет....

        • nidalee
          /#21344548

          Пробовал на МГТС с год назад — работало. Аналогично с вашей ситуацией, лишился его, подключив статику. Ну, не велика потеря.

  7. Aqarus
    /#21334462

    IPv6 хорош и прекрасен ровно до того момента, как тебе надо добавить его поддержку, например, в ембедед девайс и работать с ним на уровне чуть глубже, чем выставление режима static, dhcp или auto в /etc/network/interfaces. Практически любой, кто сталкивался с ним подтвердит это.

    • happy-cat
      /#21334478

      О да! я давеча пару недель вволю налюбился поднимая ipv6 на впсе хецнера :)
      в конце концов когда все заработало я подумал — а накуя я тратил свое время на никому не нужное? и отключил нафиг все обратно… И поверьте, мир не заметил потери бойца :)

      • ne_kotin
        /#21336464 / +1

        О да! я давеча пару недель вволю налюбился поднимая ipv6 на впсе хецнера :)

        А расскажите пожалуйста — зачем вы налюбились, когда он там по умолчанию поднят и настроен?
        eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
                inet 159.69.14.230  netmask 255.255.255.255  broadcast 159.69.14.230
                inet6 fe80::9400:ff:fe0a:f139  prefixlen 64  scopeid 0x20<link>
                inet6 2a01:4f8:1c1c:2f3d::1  prefixlen 64  scopeid 0x0<global>
                ether 96:00:00:0a:f1:39  txqueuelen 1000  (Ethernet)
                RX packets 2083718  bytes 1276850142 (1.2 GB)
                RX errors 0  dropped 0  overruns 0  frame 0
                TX packets 1391024  bytes 1220778556 (1.2 GB)
                TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        

        Просто работает. Из коробки.
        Дома на роутере (Asus средней цены, гигабитный двухдиапазонник) настроен 6in4 от HE в SLAAC, всем девайсам опять же выдаются глобальные v6-адреса.

        Ну, т.е. если в сети есть роутер с v6 аплинком и RADVD — ничего не надо делать, кроме как воткнуть кабель.

        • happy-cat
          /#21338074

          Роутер Хуавей от МГТС GPON да, сам генерит и выдает IPV6 внутри — но какой в этом смысл если тот же провайдер НЕ работает (читай никак не выпускает из своих сетей) весь IPV6 траффик…


          Касаемо Хецнера — да, интерфейс поднимается, только надо еще net.ipv6.conf.default.forwarding=1


          И таких явных и не явных моментов везде понатыкано. Я то его в итоге запустил и даже nginx настроил (мечтатель блин..) но большого смысла в этом не оказалось, поисковики больше и чаще заходить не стали, зато сканирующих ботов в той черной дыре ооочень много, для интереса гляньте raw логи — будете неприятно удивлены..

          • ne_kotin
            /#21338140

            Роутер Хуавей от МГТС GPON да, сам генерит и выдает IPV6 внутри — но какой в этом смысл если тот же провайдер НЕ работает (читай никак не выпускает из своих сетей) весь IPV6 траффик…

            А ваш Хуавей не умеет в 6in4 аплинк до Hurricane Electric, например? Мой — умеет, так и живу. HE выдал мне /64, которую раздает роутер в локалке. Все работает как задумано — есть автоконфигурация адресов, есть подсеть /64, есть глобальная связность.

            Касаемо Хецнера — да, интерфейс поднимается, только надо еще net.ipv6.conf.default.forwarding=1

            Зачем? Вы роутите несколько v6 сетей? Потому как эта опция нужна для того, чтобы разрешить форвардинг v6-трафика между интерфейсами. А достукиваться до сервера это не мешает.

            # sysctl net.ipv6.conf.default.forwarding
            net.ipv6.conf.default.forwarding = 0
            
            ~$ ping -6 2a01:4f8:1c1c:2f3d::1
            PING 2a01:4f8:1c1c:2f3d::1(2a01:4f8:1c1c:2f3d::1) 56 data bytes
            64 bytes from 2a01:4f8:1c1c:2f3d::1: icmp_seq=1 ttl=54 time=40.7 ms
            64 bytes from 2a01:4f8:1c1c:2f3d::1: icmp_seq=2 ttl=54 time=40.8 ms
            64 bytes from 2a01:4f8:1c1c:2f3d::1: icmp_seq=3 ttl=54 time=40.8 ms
            64 bytes from 2a01:4f8:1c1c:2f3d::1: icmp_seq=4 ttl=54 time=40.9 ms
            ^C
            --- 2a01:4f8:1c1c:2f3d::1 ping statistics ---
            4 packets transmitted, 4 received, 0% packet loss, time 8ms
            rtt min/avg/max/mdev = 40.683/40.810/40.908/0.217 ms
            
            ~$ ssh root@2a01:4f8:1c1c:2f3d::1
            The authenticity of host '2a01:4f8:1c1c:2f3d::1 (2a01:4f8:1c1c:2f3d::1)' can't be established.
            ECDSA key fingerprint is SHA256:aSlaF63wCFy0cX50wXacfHxm0NHDdj26wX0YdN8Glic.
            Are you sure you want to continue connecting (yes/no)? yes
            Warning: Permanently added '2a01:4f8:1c1c:2f3d::1' (ECDSA) to the list of known hosts.
            Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.15.0-22-generic x86_64)
            


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

            Ну, пока скан не вызывает отказ в обслуживании — пофигу, честно говоря, тем более, у меня там не web-сервер, а прокси к телеге. nginx кстати по дефолту настраивается слушать все v4 и v6 адреса.

          • Tolmy
            /#21338872

            поисковики больше и чаще заходить не стали,

            С чего бы им больше заходить? Для них единица измерения — доменное имя, а не адрес.


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

            Ой ли?
            "Пустой" среднемесячный трафик трафик на интерфейсе, доступном из инета по IPv4 100-160kbit/s
            по IPv6 — 2-4kbit/s
            И вот не надо про "неуловимого Джо" — в условиях гигантского адресного пространства сканирование становится сильно дорогим. Оно не исчезло полностью, особо упоротые сканят и весь IPv6, я видел примеры в логах. Но это реально сильно дороже по затратам. Можно конечно сказать, "вот будет у каждого пользователя по терабиту, будут и IPv6 сканить", но вы представляете себе, что будет в сетях IPv4, если у всех будет терабит?

    • stargrave2
      /#21334480

      Мне хватило парсинга заголовков IPv6 пакетов и его протоколов и IPv4 онных: лично у меня с IPv6 всё проще и кода меньше получалось. Реализация подмножества NDP для address resolution — очень проста и приятна тем, что это всё сетевой уровень, а не канальный как в ARP.

    • Tolmy
      /#21335958

      Как раз для embedded IPv6 в работе сильно проще. Памяти может надо чуть больше, но код — меньше.

  8. OleksiyT
    /#21335058

    Спецам хорошо, домохозяйки ничего не поймут.
    Здравствуйте, новые ботнеты.

  9. amarao
    /#21335170

    Вы меня сильно удивляете.


    Вы пишите:
    ни одна из массово используемых ОС не сможет эффективно коммутировать или маршрутизировать трафик на такой скорости.


    Конечно, можем в софте. И 10G, и 20G, и даже 40G — вполне возможно. Вот в районе 100+ уже проблемы.

    • stargrave2
      /#21335240

      Работать то будет, и bandwidth выжимать. Я имел в виду очень высокие показатели pps, для которых уже нужно что-то типа en.wikipedia.org/wiki/Data_Plane_Development_Kit использовать. Речь про то, что *из коробки*, даже чтобы иметь дело с 1Mpps, часто приходится что-то подкручивать и настраивать (https://blog.cloudflare.com/how-to-receive-a-million-packets/). Сети современные могут легко нагружать компьютеры, тогда как раньше они были очень медленными.

      • amarao
        /#21335416

        У меня 2 Mpps на OVS прекрасно переваривается, на серверах нескольколетней давности. Без dpdk. Вы даёте ссылку на статью 2015 года, а на дворе 2020.

        • stargrave2
          /#21335444

          Я не буду доказывать что DPDK (и подобные решения) не просто так возникли и используются.

          • amarao
            /#21335770 / +1

            DPDK и множество полуаппаратных акселераторов OVS'а — это вполне важно и нужно. Но оно начинает играть важную роль на цифрах, которые существенно выше, чем 1Mpps.


            10-20G современный сервер может обработать в любом варианте. Хоть мелкими пакетами, хоть крупными.


            Мой поинт был, что "медленность" современных компьютеров в обработке сетевого трафика — это такое тонкое передёргивание вендоров сетевого железа. Да, никакой сервер не переварит 100Mpps. Но редко какой сервер окажется в ситуации, что ему надо столько переваривать.

            • extiander
              /#21335934

              есть задача на 100Gbps
              поэтому смотрел что есть и как работает на бытовом железе
              в общем где то на 40 (реже 80) все упирается где то во внутренние шины. какие именно PCI/Mem/CPU не проверял, но general servers/OSes работают без мега шаманства до 40ка, дальше все

              • amarao
                /#21336188

                100G вы задёшево не протащите. (Это тезис из оригинальной статьи). Даже во времена "медленной сети" (про которую писали) были плезиосинхронные линки невиданных скоростей. Конечного оборудования они не касались.

            • stargrave2
              /#21336178

              Повторюсь: вопрос не в пропускной способности по трафику, а в кол-ве пакетов/сек. 10-20Gb трафика сервер переварит — полностью согласен. Но на 10G можно выжимать 10-14Mpps — а вот это уже сложно. Я это и хотел подчеркнуть в ответе: что существенно высокие pps-ы из коробки сложнее выжать, ибо упрёмся не в железо прежде.

              Я согласен что мало кому придётся переваривать много pps-ов. Изначально вся эта тема в статье поднята исключительно от того, что раньше каналы связи были такие медленные, что компьютер нельзя было нагрузить ими, грубо говоря. Количество перерастает в качество — сильно быстрые сети, качественно требуют существенно более простых протоколов, чтобы облегчить жизнь компьютерам, которым уже много много pps так легко не переварить.

              • amarao
                /#21336200 / +1

                Упс, моя ошибка. Я глянул мои бенчмарки и там светились цифры > 2Мpps. А сколько mpps максимум в 10G пролазит я не пересчитал (и полагал, что 1.4Mpps — это как раз 10G). Это было ошибочное предположение из которого вся моя аргументация и строилась.


                Пардон.

                • edo1h
                  /#21336546

                  а на каком железе это было? сейчас с доступностью процов на много десятков ядер ситуация быть может и изменилась

  10. edo1h
    /#21335434

    Killer-feature: link-local адреса
    Для большой организации не нужно тратить время и силы на разрезание на подсети какой-нибудь 10/8 сети, раздавая из неё адреса для маршрутизаторов, следя чтобы не пересеклось ничего.

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


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

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

    вот у меня дома два интернет-провайдера, в офисе три. как это будет работать без nat? получать as и поднимать bgp? в офисе ещё можно попробовать, но дома-то?!?


    хотя и в офисе проблемы, вполне нормальная ситуация, когда в каком-то филиале падает интернет, на несколько дней ставится 4g-модем и всё работает. что будет в случае использования глобальных префиксов?


    P.S. главное, пока полно софта (и оборудования), поддерживающего только ipv4. то есть от внедрения ipv6 никакие проблемы ipv4 никуда не денутся, только добавится ещё возня с ipv6.

    • stargrave2
      /#21335492

      Для общения маршрутизаторов, зачастую, как-раз, и не нужно как таковые внутренние маршрутизируемые сети. Нужно общение link-to-link, не более.

      В чём проблема с вашим multi-homing-ом? В чём проблема с BGP? NAT не вариант в принципе: за ним не работает куча протоколов и нет связанности между хостами.

      Я давно не встречал софта не поддерживающий IPv6.

      • edo1h
        /#21335524

        чём проблема с вашим multi-homing-ом?

        какие адреса должны быть в локалке?


        В чём проблема с BGP?

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


        NAT не вариант в принципе: за ним не работает куча протоколов

        и кто вам поверит, когда у каждого дома стоит wifi-роутер с nat?


        и нет связанности между хостами

        +vpn


        Я давно не встречал софта не поддерживающий IPv6.

        вот только сегодня смотрел прогу для управления холодильной камерой. никакого ipv6 не увидел.

        • stargrave2
          /#21335554

          Я для начала не пойму что именно вам нужно с вашим multihoming-ом. Если отправлять ответные пакеты на интерфейс с которого пришли (самое распространённое желание) — решается множеством способов, без BGP.

          У всех этих людей дома с WiFi-роутером есть Интернет? Я им не верю. Удалённый доступ за NAT-ом вовне — есть. Интернетом я это не могу назвать.

          VPN? Вы серьёзно? Начали с IPv6 с сплошными белыми адресами, закончили NAT+VPN как возможное решение?

          Ну… прога для управления камерой может и не умеет. Будем считать что отсталость софта для холодильных камер тормозит внедрение IPv6.

          • edo1h
            /#21335778

            Я для начала не пойму что именно вам нужно с вашим multihoming-ом

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


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


            Скрытый текст

            это мы считаем, что светлое будущее уже наступило и второй провайдер тоже стал предоставлять ipv6

            • stargrave2
              /#21336204

              Всё что вы описали для multihoming делается людьми всякими source based routing policies (например): как-раз это самая распространённая задача когда несколько провайдеров. NAT или BGP она не требует.

              Зло это NAT :-). Site-local имеет право на существование (я у себя и дома его использую для транспорта IPsec туннелей), но нужно *очень* хорошо задуматься нужен ли он. Что будет плохого в том, что вы в локальной сети с 1С и прочими будете использовать глобальные адреса? Вы же в любом случае firewall-ом и так будете обеспечивать безопасность и невозможность подключения к ним из вне (или, скорее всего, напишете IPsec security policy говорящий что из вне только с ESP шифрованием). Так какой смысл в site-local? Так как site-local часто будет каким-нибудь fc::/64 (или /7), то есть отнюдь не нулевая вероятность что у кого-нибудь дома такое же используется, а он захочет подключиться туннелем к сети предприятия (удалённая работа). Смысла не использовать имеющиеся глобальные адреса просто нет, как минимум они дают гарантирю что не пересекутся с инфраструктурой кого-нибудь другого.

              Если вам нужна невозможность подключения извне — для этого есть firewall.

              • edo1h
                /#21336302

                Что будет плохого в том, что вы в локальной сети с 1С и прочими будете использовать глобальные адреса?

                Я вроде несколько раз отвечал на этот вопрос. Чей будет адрес? Провайдера? У меня их в центральном офисе больше одного. Свой? Тогда мне нужно озаботиться as и bgp. Не то, что это было так уж плохо, но мы сейчас приходим к тому, что во всех периферийных точках тоже должны быть резервные каналы (хотя бы в виде 4g-модема). Поднимать по as на каждую точку с несколькими пользователям? (а у меня их несколько сотен)

                • stargrave2
                  /#21336468

                  Любой из префиксов провайдера. Если вы не хотите извне к ним подключаться, то зачем вам задумываться о BGP/AS и подобном? Просто вместо fc:: используйте один из префиксов любого вашего провайдера, исключительно для того, чтобы знать что эти прописанные в локальной сети префиксы никем не будут более заняты, как это легко произойдёт с fc/7 сетью, используемой cjdns и наверное ещё кем-нибудь.

                • stargrave2
                  /#21336480

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

                  • edo1h
                    /#21336552

                    а не получится, что завтра я ушёл от этого провайдера — и он те адреса отдал кому-то ещё

                    • stargrave2
                      /#21336584

                      Если ушли, то безусловно легко отдаст. Парировать этот аргумент не могу, признаю. Но неужели вероятность того, что у вас ну вообще нигде не найдётся префиксов которые вы вряд ли будете менять, выше чем вероятность коллизий с fc/ сетью любого произвольного сотрудника или того, что вы не захотите соединить VPN-ом две корпоративные сети и вам fc/ на обоих концах помешает? Если вероятность выше, то да, стоит использовать fc::.

                      • edo1h
                        /#21336616

                        да вроде бы получить PI блок несложно.


                        только вот я не вижу потребности в переходе на ipv6 в корпоративной сети, а dual stack… не, подождём ещё лет пять, а потом ещё раз вернёмся к этому вопроcу.

                        • stargrave2
                          /#21336634

                          Ну многие плюсы IPv6 описаны тут: habr.com/ru/post/490378. Если IPv4 хочется иметь только для хождения по сайтикам из корпоративной сети, то можно использовать (я делал — работает) NAT64+DNS64. IPv4 dual stack хотя бы будет только на маршрутизаторе.

    • Tolmy
      /#21335922

      У меня есть работодатель, у которого в корпоративной сети только IPv6. Они решили, что поддерживать такое проще и дешевле, чем городить зоопарк из частных сетей, vpn, nat и целенаправленно к этому шли пару лет. Как там результаты, к примеру, по финансам и трудовым ресурсам — я не знаю, но доступ к внутренней инфраструктуре снаружи сильно упростился. И нет, не стал от этого более небезопасным, IPsec, все дела, всё на месте. Админить такое — чистое удовольствие. И да, поскольку теперь дома IPv6 у меня must have, то я все свои домашние сервисы перевел в IPv6 only. Это реально очень удобно. Понятно, что исчезновением лично меня с моим десятком хоббийных сайтов из IPv4 пространства никто этого не заметил, да и те несчастные, кто попытавшись открыть напрямую ссылку из поиска гугла никуда попасть не могут, но всегда могут "открыть сохраненную страницу", но рано или поздно эта тенденция таки станет массовой.

      • edo1h
        /#21336094

        но доступ к внутренней инфраструктуре снаружи сильно упростился

        я правильно понимаю, это "сильно упростился" — это ipv6-туннель (большинство же провайдеров не предоставлят нативного ipv6) + ipsec? это правда проще, чем l2tp или openvpn с конфигом в несколько строчек?

        • stargrave2
          /#21336230

          Я гарантирую что это существенно проще и сильно удобнее. На своём опыте это всё познал. OpenVPN… с этим я совершенно не хочу больше иметь дела после удобства IPsec (при наличии IPv6). Как минимум, я в живую вроде даже и не видел OpenVPN с современными алгоритмами шифрования/аутентификации: AES-GCM, ChaCha20/Poly1305 уже давно в IPsec есть. OpenVPN, мягко говоря, архаичен. Если не IPsec, я бы уж в сторону WireGuard посмотрел бы.

          • a1888877
            /#21336268

            В OpenVPN есть все алгоритмы из OpenSSL, включая AES-GCM, ChaCha20/Poly1305. А вот с IPSec, наоборот поддержка алгоритмов очень слабая и, что ещё хуже разная на разных устройствах. Того же ChaCha20 нет даже в Windows 10, а к примеру, в 8.1 он никогда и не появится. Поэтому в гетерогенной среде, где разные клиенты, IPSec совсем не так хорош, как хотелось бы.

            • stargrave2
              /#21336406

              Согласен что IPsec современные алгоримы есть не везде. В моём текущем OpenVPN действительно AES-GCM обнаружился, а вот на работе поддерживаются только не-AEAD алгоритмы. В любом случае это не столь критично всегда, но если уж попридираться к производительности, то последний раз когда я работал с OpenVPN, то это был user-space однопоточный демон, в котором я всегда упрусь в одно ядро процессора. IPsec параллелится (как правило). Плюс OpenVPN это переключение в user-space для дешифрования, затем переключение в ядро для дальнейшей маршрутизации пакета. Всё это, само собой, не помеха и не проблема для преобладающего большинства пользователей, но всё же c IPsec эффективностью сложно конкурировать (конечно, зависит от конкретной реализации).

              IPsec далёк от идеала, не спорю. Но… при всех своих недостатках, для меня он однозначно лучший выбор чем OpenVPN, который худший выбор, особенно с наличием WireGuard. И я уж лучше SSH-TUN туннель бы поднял, но не OpenVPN. Но эта тема не касается IPv6 :-). OpenVPN можно и поверх IPv6 использовать наверняка.

              • edo1h
                /#21336564

                И я уж лучше SSH-TUN туннель бы поднял, но не OpenVPN

                ну это уже религиозное ИМХО

                • stargrave2
                  /#21336590

                  Ну SSH сервер/клиент на любой *nix машине будет, а на сервере наверняка уже запущен, а OpenVPN из коробки я не помню чтобы шёл в каком дистрибутиве. Тупо удобнее.

              • Tolmy
                /#21337050

                OpenVPN давно умеет из коробки и ходить по IPv6 транспорту, и пускать IPv6 в туннеле.

            • stargrave2
              /#21336452

              Самое то главное: IPsec это не про VPN. Им можно туннелировать пакеты (целые сети), но в нём есть транспортный режим и стандартный setsockopt вызов позволяет буквально per-socket шифровать (TCP/UDP/whatever) IP пакеты. Сейчас IPsec в головах людей это VPN, потому что в IPv4 мире транспортный режим, грубо говоря, не получится использовать, ибо нет host-to-host связанности. IPsec это штука которая в транспортном режиме может полностью заменить то, что сейчас делает TLS. Но это тоже придирка: IPsec это всё же существенно сильно шире чем просто VPN.

        • Tolmy
          /#21337048

          Я помахал ручкой одному провайдеру, который сказал "IPv6 нет и не предвидится" и подключился к другому, у которого /64 из коробки и можно бесплатно просто по письму получить ещё /56
          И обхожусь без ipv6-туннелей. (Хотя вот прямо сейчас я не дома и тут у меня да, ipv6 туннель)
          И да, это проще и понятнее, чем l2tp. Потому что разделено на две назависимые сущности — туннель и шифрование.

      • stargrave2
        /#21336238

        Ещё можно было бы сделать NAT64+DNS64 и тогда IPv4 сайты смотреть IPv6-only пользователям, без IPv4 сети внутри корпоративной сети. Но… это уже безусловно усложнение администрирования и вновь притягивание IPv4 мира, но как временная мера оно вполне работоспособно.

  11. edo1h
    /#21335478

    Некоторые well-known multicast адреса позволяют легко узнать какие компьютеры вообще есть в сети (broadcast домене Ethernet-а)

    в ipv4 не так?

    • stargrave2
      /#21335506

      Попробуйте. Нет, не так.

      • edo1h
        /#21335550

        попробовал


        PING 10.0.0.255 (10.0.0.255) 56(84) bytes of data.
        64 bytes from 10.0.0.43: icmp_seq=1 ttl=255 time=0.189 ms
        64 bytes from 10.0.0.46: icmp_seq=1 ttl=255 time=0.206 ms (DUP!)
        64 bytes from 10.0.0.45: icmp_seq=1 ttl=255 time=0.223 ms (DUP!)
        64 bytes from 10.0.0.44: icmp_seq=1 ttl=255 time=0.224 ms (DUP!)
        64 bytes from 10.0.0.24: icmp_seq=1 ttl=255 time=0.337 ms (DUP!)
        64 bytes from 10.0.0.247: icmp_seq=1 ttl=100 time=1.54 ms (DUP!)
        64 bytes from 10.0.0.16: icmp_seq=1 ttl=64 time=2.88 ms (DUP!)
        64 bytes from 10.0.0.249: icmp_seq=1 ttl=100 time=5.16 ms (DUP!)
        64 bytes from 10.0.0.248: icmp_seq=1 ttl=100 time=7.35 ms (DUP!)

        • stargrave2
          /#21335564

          Ну я вот в трёх совершенно разных сетях (где есть IPv4) проверил, firewall точно не мешает, но 0 packets received, 100.0% packet loss. Так что нет, не работает это из коробки вот нигде. Это в сетях и с Windows и GNU/Linux и FreeBSD и с умными и тупыми коммутаторами.

          • edo1h
            /#21335696

            в линуксе это


            sysctl net.ipv4.icmp_echo_ignore_broadcasts=0

            да, сейчас везде по умолчанию выключено. честно говоря, не знаю по каким причинам, но странно считать преимуществом ipv6 то, что пока в нём это не отключают.

            • stargrave2
              /#21335722

              Странно это отключать в IPv6 мире, где всё-равно NDP активно использует multicast и в принципе он активно участвует в жизни хостов, в отличии от IPv4.

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

  12. powerman
    /#21335692 / +1

    А в чём смысл выдавать каждому пользователю /64? Нет, я допускаю, что это может заметно разгрузить таблицы маршрутизации на роутерах, но если не фокусироваться на ограниченных возможностях роутеров — зачем это нужно? По сути ведь это просто бессмысленное уничтожение громадного количества адресов — ведь у абсолютного большинства пользователей, даже после выдачи IP каждой лампочке в доме и каждому контейнеру докера, будет реально использоваться несколько сотен адресов максимум. Хотите выдать с диким запасом, чтобы хватило навсегда — ну выдайте /112, это 64K адресов каждому. А при выдаче всем /64 мы, по сути, минимум 48 бит адресного пространства выкидываем в мусор… что возвращает нас к изначальному вопросу: для чего это нужно?

    • stargrave2
      /#21335716

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

      На самом деле у меня такой же вопрос: разве это не слишком ли расточительно. Ну коммитеты посчитали что вроде нет, должно хватить даже так, даже выдавая /56 или /48 конечным пользователям. Но, на данный момент все адреса выдаются только из 2000::/3 — используется 1/8 всего возможного пространства. Если же умные коммитеты обосрались с рассчётами и прикидыванием, то у нас есть ещё 7 попыток, где могут быть в корне совершенно другие политики выдачи.

      • powerman
        /#21336220

        Отличная новость! Т.е. люди, которые потенциально таки совершили эту ошибку, из 128 бит умудрились оставить нам всего 7 попыток сделать правильно?

        • stargrave2
          /#21336248

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

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

    • stargrave2
      /#21335738

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

      Потери при выдаче /64 будут не /48 бит, а все 60-62, ведь у многих буквально несколько устройств всего-лишь подключено. Но не стоит забывать что и подходы работы в IPv6 сетях надо менять и не ютиться на одном IP-адресе. Лично я вот не редко выношу некоторые службы на отдельные IP, чтобы персонально к этим IP применять IPsec политики. Это просто удобно. Возможно массово это никто и не будет использовать, а возможно нам и этого будет не хватать — никто не знает что будет в будущем.

    • Tolmy
      /#21335884

      /64 хосту позволяет использовать RFC 4941 — Privacy Extensions for Stateless Address
      И все скрипты, которые обходят весь интернет для поиска открытых ssh портов превращаются в тыкву, потому что теперь каждый хост в IPv6 — это как весь интернет в IPv4(нет, в реальности гораздо больше)

      • powerman
        /#21336214

        Честно говоря, я ждал этого аргумента. Риторический вопрос: не кажется ли Вам, что прятать порт ssh таким образом — это дикий overkill? Я уже молчу о том, что многие в IPv6 всё-равно поставят адреса вроде …::1 чтобы ленивее было набирать/запоминать/различать, что можно перевесить ssh на нестандартный порт, и, главное, что если защита периметра строится на том, что порт ssh не найдут, то у меня для Вас плохие новости…

        • stargrave2
          /#21336344

          Думаю что почти наверняка всё что предполагает соединение извне или прописывает себя в DNS или, как вы верно про ::1 заметили, конфигурируется руками статично. Лично я аргументом тоже не могу считать безопасностью невозможность перебора адресов.

        • Tolmy
          /#21337062

          Речь про другое. Речь скорее про компы обыкновенных пользователей, у которых проблемы с безопасностью из-за их безалаберности. Не нравится вам 22-й порт, окей, пусть это будет 3389. Суть от этого не меняется. в IPv4 сети сканером одного порта полностью обходится весь интернет за несколько часов. В IPv6 на это уйдут месяцы, даже если сканить только уже распределенные сети, не трогая зарезервированные и неиспользуемые. Это в общем случае не безопасность "меня никогда не найдут", а значительное увеличение стоимости атаки. Поэтому отпадет огромное количество мамкиных кулхацкеров, поскольку вероятность получить результат за приемлемое время сильно падает. А ещё это не такой стремительный рост ботнетов, это тоже пассивная безопасность, потому что ботнеты на сотни тысяч пораженных устройств позволяют легко делать то, что меньшим количеством просто не делается.

          • powerman
            /#21338694

            Есть способы сильно эти "месяцы" сократить, не без своих ограничений, но, тем не менее. И увеличение стоимости атаки получается уже не столь значительным, как нам бы хотелось. Вот, быстро погуглил, и сразу попался список подходов (скорее всего далеко не окончательный):


            • When nodes are allocated sequential IIDs addresses such as ::1, ::2, ::3, ::4, …
            • When nodes have their IPv6 address in DNS zones that can be queried
            • When nodes respond to an ICMPv6 echo-request sent to the all-nodes link-local multicast (FF02::1)
            • When nodes respond to an invalid extension header sent to the all-nodes link-local multicast (FF02::1)
            • When nodes respond to an MLD query send to the all-nodes link-local multicast (FF02::1)
            • When nodes send an ICMPv6 type 135 Neighbor Solicitation (NS) for a rogue default router sending an ICMPv6 type 134 Router Advertisement (RA)
            • Using other methods of leveraging IPv4 to learn the IPv6 address of the dual-protocol node
            • If all the nodes on the network use SLAAC and EUI-64 with the same Ethernet NIC OUI. In this case, the first 24 bits of the IID will all be the same, the next 16 bits of the IID are FFFE, followed by the unique 24 bits of the node’s MAC address. Scanning 2^24 IPv6 addresses might take only a few days.

            • Tolmy
              /#21338886

              Ни один из методов не работает на обычной Windows 10, получившей IPv6 адрес по SLAAC. В которой пользователь даже не знает, что надо что-то там настраивать. Купил в магазине нотбук и пользуется. Напоминаю, если что, это и есть порядка 95% всех хостов в интернете. А сервера, что сервера, у серверов должны быть админы. Так что мой тезис скорее подтверждается, чем был опровергнут.

  13. a1888877
    /#21335946 / +1

    В статье повторяется мантра про «продуманный», «эффективный», «удобный» — только это не про IPv6. Он уже четверть века как не может заменить IPv4, потому что является крайне не удачным протоколом на фоне предшественника.
    Метания с DHCP (а сделаем два протокола — RA и DHCPv6), NAT (абсолютное зло, а добавим IPv6-to-IPv6 NPT), диапазонами (fec0:/fc00:: или ::ipv4/::ffff:ipv4), EUI из MAC/рандомно, меняющаяся длина префикс (6 vs 8) прекрасно демонстрируют компетенции авторов IPv6.

    — Удаленный доступ: NAT + маршрутизация провайдера надежно закрывает абонентские терминалы, на которых некоторые пользователи так любят отключать межсетевые экраны. IPv6 автоматом несет коллапс ИБ.
    — NAT иногда нужен вовсе не для экономии адресов, а для эмуляции окружения сегментов сетей. И заменить его нечем. И, да, читаем про IPv6-to-IPv6 NPT.
    — IPSec/ESP вполне себе работает и в IPv4/NAT. Но, всё же OpenVPN, Wireguard, SSH/TLS проще и в настройке и как протоколы (а значит и потенциально менее уязвимы).
    — «минимум /64 сеть» — обман из 90-х, когда оверинженериг создателей IPv6 не ограничивался реальностью. Сейчас конечному пользователю такую сеть уже почти никто не выдаст.
    — Идея использовать глобальный префикс прекрасна, если помнить, что провайдер, которому этот префикс принадлежит может и поменяться. Вместе с префиксом.
    — Я честно не смог найти мнемонику между 2a02:6b8::2:242 и ya.ru — и назвать четыре числа простому пользователю, не смыслящему в этих ваших сетях и английском, сильно проще чем многосимвольную щестнадцатиричную «штуку».
    — Насчет иерархии IPv6 адресов. Старые сетевые инженеры помнят, зачем в древних cisco нужно включать бесклассовую маршрутизацию и почему в 80-х от неё отказались. Думаю, со временем откажемся и здесь.
    — link-local были прекрасно сделаны в Windows и без IPv6, показывая, что переделывать сетевые протоколы ради автоматически настраивающихся сетей не требуется.
    — well-known multicast адреса в IPv4 назвались широковещательным пингом — и его похоронили ради безопастности. Удивительно, что теперь это преподносится как преимущество.
    — Магия SLAAC уходит, когда мы вспоминаем про обычные роутеры с 192.168.1.1/24 и DHCP — ведь для простого пользователя ничего не меняется.
    — Магия anycast уходит, когда выясняется, что в отличии от существующего сейчас Anycast, здесь эти адреса нельзя использовать в качестве адресов отправителей.
    — В IPv6 вообще то НЕ фиксированные заголовки из-за extension headers. И агитация IPv6, в которой их якобы отсутствие преподносится преимуществом хороший пример переусложненности протокола.
    — Flow Label сложно сказать насколько жизнеспособно, пакеты не фрагментируются до нечитаемости заголовков TCP/UDP/SCTP и я не уверен, что он когда-либо будет применен в живых системах из-за потенциальных проблем с безопасностью при балансировке нагрузки.
    — Multicast NDP работает в Ethernet сетях так же как и ARP/DHCP. Вот если у вас X.25, тогда да, нагрузка на сеть будет меньше (RFC 4861).
    — NDP NUD в общем-то действительно плюс. Одна из базовых причин продвижения Google своего QUIC вместо связки IP/TCP/TLS.
    Плюс 128 битные адреса, которые на самом деле 64 битные, поскольку последние 8 байт генерирует EUI из MAC адреса устройства. Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско. А потом в целях безопасности, что бы не светить MAC, заменим это случайным числом — действительно, в заголовке каждого пакета, два 8 байтных случайных числа, вместо полезных данных. Действительно IPv6 — «эффективный» и «продуманный» протокол.

    Ну и главный минус IPv6 — это заведомо заложенная несовместимость с IPv4, какие-то работоспособные варианты Dual Stack стали появляться лет через 10-15, после выхода протокола — и это очень сильно тормозило его внедрение. Удивительно, как имея IPv4 — далеко не идеальный и не беспроблемный протокол, десять лет его эксплуатации в живых сетях и решения проявившихся проблем можно было создать IPv6.

    • aram_pakhchanian
      /#21336150

      У меня есть простой принцип: если человек пишет полный негатив, то его позицию вряд ли можно считать объективной. Впрочем, и позиция автора статьи тоже далека от объективности.

      «минимум /64 сеть» — обман из 90-х, когда оверинженериг создателей IPv6 не ограничивался реальностью. Сейчас конечному пользователю такую сеть уже почти никто не выдаст.


      У меня дома /56. Пожаловаться на провайдера?
      Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско.

      В чем фиаско-то? Ну дублирует.

      • a1888877
        /#21336206

        Справедливости ради, NDP NUD я похвалил. Остальное по пунктам соответствует тезисам автора статьи.
        Насчет /64 я ошибся — комментарий слишком длинный вышел, а аспектов связанных с IPv6 много. Имелось в виду сужающееся пространство — изначально, конечным пользователям планировали давать /48. Потом начали сокращать — у вас /56, у кого-то до /64. Меньше в текущих реалях уже нельзя.
        Насчет дублирования — эти байты лишние. Если их убрать из заголовка, то на работоспособности протокола это не скажется. Но из-за них длина адреса сокращается вдвое и каждый пакет (от 300 до 1500 байт) содержит лишние 16 байт — меньше пропускная способность сетей, больше энергопотребление и т.д…

        • aram_pakhchanian
          /#21336244

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

          • a1888877
            /#21336362 / +1

            IPv6 это сетевой протокол — его нельзя просто так взять и заменить на оптимизированный, когда/если проект «взлетит». Он должен быть оптимален изначально. Да и для решения «боли» там есть extended headers в которые можно положить всё забытое при стандартизации. Хотелось бы конечно верить, что авторы IPv6 разбирались в сетях и были гениальны настолько, что остались не поняты. Однако, критерий истины — время. То как RFC сменяли друг друга и менялся конгломерат протоколов IPv6 указывает на многочисленные ошибки его авторов. И то, как IPv6 25 лет пытается заменить IPv4 тоже свидетельствует о некоторых проблемах, потому как IPv4 пусть и не мгновенно, но несколько десятков аналогов и конкурентов вынес. Я тот же IPX через wiki кое-как нашел, а он лишь один из многих, ныне забытых.

            • aram_pakhchanian
              /#21338068

              IPX был куда лучше для локальных сетей, чем TCP/IP, но совершенно не работал в глобальном пространстве. Помню, как мы долго плевались, когда переходили с IPX на TCP/IP в офисе в начале 90-х, и переходили только потому, что нужно было с компов выходить в интернет. IPX не проиграл, он просто автоматом вышел из игры, но стал популярен с нуля и выигрывал у tcp/ip почти 15 лет при том, что tcp/ip существовал с начала 80-х как официальный стандарт. Ровно так же автоматом уйдёт ipv4, потому что в мире IOT он не релевантен.

              • powerman
                /#21338726

                в мире IOT он не релевантен

                С миром IoT всё сложно, на самом-то деле. Он ещё не наступил, и пока неясно, наступит ли. У него уже проявилось две большие проблемы, у которых пока что решения нет: во-первых китайские умные лампочки и прочие вибраторы/радионяни с "закладками" стучащие домой (а потом с серверов компании всё это утекает в паблик), и во-вторых "окирпичивание" умных устройств если что-то случается с серверами компании-производителя.


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


                Эти проблемы, конечно, решаемые. Но это решение сильно удорожит продукт, и вполне может сделать большую часть IoT нерентабельным.

                • aram_pakhchanian
                  /#21338850

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

                • Ankoroid
                  /#21340584

                  Проблемы с IoT для корпоратов будут решены 5G слайсами и стыками MPLS.
                  Никакие «лампочки» никуда попадать не будут и до них будет не достучаться.

                  Ну а физики должны страдать, они же хотят все нахаляву :)

    • stargrave2
      /#21336348

      >Он уже четверть века как не может заменить IPv4, потому что является крайне не удачным протоколом на фоне предшественника

      Он не может заменить из-за инертности мышления людей, и банально из-за того, что Интернет, как таковой, мало кому нужен. Деньги приносят конечные пользователи. А им нужен удалённый доступ к ряду сервисов.

      >— Удаленный доступ: NAT + маршрутизация провайдера надежно закрывает абонентские терминалы, на которых некоторые пользователи так любят отключать межсетевые экраны. IPv6 автоматом несет коллапс ИБ.

      Отсутствие Интернета (возможность общения хостов между собоу) означает повышенную безопасность. Да, я это от многих уже слышал и считаю маразмом. Отключите кабель — будет ещё безопаснее. Потому что пользователи и без firewall-а умудрятся что-нибудь сделать небезопасное.

      >— NAT иногда нужен вовсе не для экономии адресов, а для эмуляции окружения сегментов сетей. И заменить его нечем. И, да, читаем про IPv6-to-IPv6 NPT.

      Не нужно смешивать людей придумывавших IPv6/NDP/etc с всегда-найдётся-человеками которые придумают нечто странное. В RFC много всякого странного и ненужного.

      >— IPSec/ESP вполне себе работает и в IPv4/NAT.

      С костылями в виде NATT. А если оба за NAT-ом, то тут как всегда…

      >Но, всё же OpenVPN, Wireguard, SSH/TLS проще и в настройке и как протоколы (а значит и потенциально менее уязвимы).

      Зависит от IKE демонов. Настройка strongSwan — одно удовольствие и возвращаться к OpenVPN никогда. TLS — только версия 1.3 выглядит достойно с криптографической точки зрения. Среди всех вышеназванных протоколов (кроме ультрасовременного WireGuard) — только IPsec за свою историю не имел криптографических проблем. Даже первые версии ESP и IKE имеют отличный уровень безопасности.

      >— «минимум /64 сеть» — обман из 90-х, когда оверинженериг создателей IPv6 не ограничивался реальностью. Сейчас конечному пользователю такую сеть уже почти никто не выдаст.

      Это явно не соответствует правде. Нигде не встречал чтобы выдавали меньше.

      >— Идея использовать глобальный префикс прекрасна, если помнить, что провайдер, которому этот префикс принадлежит может и поменяться. Вместе с префиксом.

      Да, и все NDP/MIPv6 и прочие заточены под то, что всё может меняться. В SLAAC-е даже lifetime-ы есть из серии часов для префикса/адреса.

      >— Я честно не смог найти мнемонику между 2a02:6b8::2:242 и ya.ru — и назвать четыре числа простому пользователю, не смыслящему в этих ваших сетях и английском, сильно проще чем многосимвольную щестнадцатиричную «штуку».

      Тут мнемоники нет. Это просто короткий и запоминающийся адрес. Нет, безусловно с «8.8.8.8»/«8.8.4.4» ничто не может соревноваться, но на практике адреса всё-равно достаточно короткие и легко запоминающиеся.

      >— Насчет иерархии IPv6 адресов. Старые сетевые инженеры помнят, зачем в древних cisco нужно включать бесклассовую маршрутизацию и почему в 80-х от неё отказались. Думаю, со временем откажемся и здесь.

      Помнят, потому что классовая адресация крайне нерационально использовала пространство адресов и чтобы моментально не произошёл коллапс от нехватки всего IPv4 пространства — придумали CIDR. Только причём тут иерархия и классовость/безклассовость? В IPv4 мире нарезали на маленькие кусочки и маршрутизировали хаотично, потому что кому как и где уж выдали.

      >— link-local были прекрасно сделаны в Windows и без IPv6, показывая, что переделывать сетевые протоколы ради автоматически настраивающихся сетей не требуется.

      Про Windows не знаю. Но вот вне Windows как-то не прижилось.

      >— well-known multicast адреса в IPv4 назвались широковещательным пингом — и его похоронили ради безопастности. Удивительно, что теперь это преподносится как преимущество.

      Удивительно, но в IPv4 мире любят даже ICMP полностью блокировать, уничтожая возможность делать PMTUD, считая что у кого не native-1500-bytes-MTU — нищеброд и сам виноват.

      >— Магия SLAAC уходит, когда мы вспоминаем про обычные роутеры с 192.168.1.1/24 и DHCP — ведь для простого пользователя ничего не меняется.

      Не понял причём тут какой-то 192.168.1.1, SLAAC и DHCP.

      >— Магия anycast уходит, когда выясняется, что в отличии от существующего сейчас Anycast, здесь эти адреса нельзя использовать в качестве адресов отправителей.

      Это явно не соответствует действительности. Я даже не знаю откуда такое вы взяли или увидели.

      >— В IPv6 вообще то НЕ фиксированные заголовки из-за extension headers. И агитация IPv6, в которой их якобы отсутствие преподносится преимуществом хороший пример переусложненности протокола.

      Решения о маршрутизации принимаются на основе фиксированного заголовка. Почти все расширенные маршрутизатор в общем-то может игнорировать. Полная картина — не фиксирована. Для маршрутизаторов — фиксирована.

      >— Flow Label сложно сказать насколько жизнеспособно, пакеты не фрагментируются до нечитаемости заголовков TCP/UDP/SCTP и я не уверен, что он когда-либо будет применен в живых системах из-за потенциальных проблем с безопасностью при балансировке нагрузки.

      Действительно flow label на практике ещё не понятно насколько полезен. Но вредит он максимум только наличием 20 лишних бит — попытка не пытка.

      >— Multicast NDP работает в Ethernet сетях так же как и ARP/DHCP. Вот если у вас X.25, тогда да, нагрузка на сеть будет меньше (RFC 4861).

      Не всегда так, но да, он может превратиться в broadcast.

      >Плюс 128 битные адреса, которые на самом деле 64 битные, поскольку последние 8 байт генерирует EUI из MAC адреса устройства.

      На самом деле они 128 битные, посколько никто вас не обязывает использовать только этот один автоматический EUI64 адрес. Вы можете сгенерировать ещё 1<<64-XXX адресов. То что современные приложения учаться «ужиматься» на куче портов на одном единственном IP адресе — да, факт. IPv6 это другой мир, где для *более* эффективной работы стоит применять другие подходы. В самом адресе уже можно зашивать «порты», экономя на более простых транспортных заголовках, например.

      >Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско.

      Ну не половина, а 48-бит. И IP не предполагает использование исключительно поверх Ethernet/WiFi сетей. Канальный уровень может быть любым. И в идеале он должен быть point-to-point без ненужного (для IPv6 мира) overhead-а от адресов канального уровня.

      >А потом в целях безопасности, что бы не светить MAC, заменим это случайным числом — действительно, в заголовке каждого пакета, два 8 байтных случайных числа, вместо полезных данных. Действительно IPv6 — «эффективный» и «продуманный» протокол.

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

      >Ну и главный минус IPv6 — это заведомо заложенная несовместимость с IPv4

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

      • edo1h
        /#21336444

        Удивительно, но в IPv4 мире любят даже ICMP полностью блокировать

        И сразу же


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

        Спасибо за отличный пример двойных стандартов

      • powerman
        /#21336490

        Он не может заменить из-за инертности мышления людей,

        Это не так — за это же время сменились целые эпохи в других областях, и инерция мышления этому не помешала.


        и банально из-за того, что Интернет, как таковой, мало кому нужен.

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


        Отсутствие Интернета (возможность общения хостов между собоу) означает повышенную безопасность. Да, я это от многих уже слышал и считаю маразмом.

        Всё так. Любой файрвол по своей сути эту связность ломает, это его работа — блокировать небезопасные связи. А Интернет большинству не нужен, как мы уже выяснили. (А кому нужен — мне, например — тот давно получил у провайдера белый IP.)


        Не нужно смешивать людей придумывавших IPv6/NDP/etc с всегда-найдётся-человеками которые придумают нечто странное.

        Вот, кстати, хороший вопрос: а как без этого "странного" в IPv6 предполагается обходить блокировки и вообще маскировать свой адрес от слежки? Ну, то самое, для чего сегодня поднимается VPN, на котором NAT?


        Зависит от IKE демонов. Настройка strongSwan — одно удовольствие … (кроме ультрасовременного WireGuard)

        Но зачем же исключать WireGuard? Он как раз хорошо показывает, как на самом деле просто всё это должно настраиваться, и настройку strongSwan на его фоне воспринимать удовольствием… ну, немного отдаёт мазохизмом. От большой любви к IPv6, конечно же, можно на это закрыть глаза, но если смотреть объективно…


        2a02:6b8::2:242 … на практике адреса всё-равно достаточно короткие и легко запоминающиеся.

        А это уже отдаёт Стокгольмским синдромом. На всякий случай уточню: нет, этот адрес не короткий, и нет, не легко запоминающийся.


        Удивительно, но в IPv4 мире любят даже ICMP полностью блокировать

        Ничего удивительного, просто он создавал проблемы с безопасностью когда-то, а потом все тупо копировали уже не очень актуальные правила файрвола со stackoverflow. В этом смысле ICMPv6 скорее всего будет ещё более проблемным, потому что он более сложный и нагруженный функционалом, так что с безопасностью у него может быть заметно хуже. Собственно, быстрый поиск это элементарно доказывает: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=icmpv6

        • stargrave2
          /#21336534

          >Это не так — за это же время сменились целые эпохи в других областях, и инерция мышления этому не помешала.

          Это так, так как видно что помешала. Это не единственная причина. Стоимость оборудования (особенно в 90-х и 2000-х, когда оно не держало IPv6), ненужность провайдерам и конечным пользователям, и т.д…

          >А кому нужен — мне, например — тот давно получил у провайдера белый IP.

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

          >в IPv6 предполагается обходить блокировки и вообще маскировать свой адрес от слежки? Ну, то самое, для чего сегодня поднимается VPN, на котором NAT?

          VPN-ы которые я поднимал и которыми пользовался — были без NAT. Вопрос блокировок, анонимизации и прочего, мягко говоря, выходит за рамки эффективной сети передачи данных (IP). Можете посмотреть моё выступления на тему анонимизации :-): www.youtube.com/watch?v=FJ68Kha78Lo
          Анонимизация и эффективность работы — даже не вспомню чтобы были не на разных чашах весов.

          >Но зачем же исключать WireGuard? Он как раз хорошо показывает, как на самом деле просто всё это должно настраиваться, и настройку strongSwan на его фоне воспринимать удовольствием… ну, немного отдаёт мазохизмом. От большой любви к IPv6, конечно же, можно на это закрыть глаза, но если смотреть объективно…

          1) Исключаю потому что он появился *совсем* недавно. Грубо говоря, год назад мы бы о нём не заикнулись. А так да: он хорош. 2) IPsec это не VPN. IPsec может использоваться для VPN, но он может даже для обеспечения безопасности per-socket использоваться. WireGuard это только VPN.

          >2a02:6b8::2:242 … На всякий случай уточню: нет, этот адрес не короткий, и нет, не легко запоминающийся.

          На всякий случай напомню, что он достаточно короткий для запоминания, в отличии от мифа о том, что все адреса всегда длинные (128 бит!) типа 2a03:5a00:17:123:50c2:1bff:fea8:dd3.

          >В этом смысле ICMPv6 скорее всего будет ещё более проблемным

          Любая новая и более сложная технология (решающая больше задач) (и софт) потенциально такой будет, очевидно. Автомобили тоже требовали десятилетий опыта, отладки, и высокой квалификации для обслуживания и создания, в отличии от лошадей которых только приручить и впрячь в повозки. Это всё очевидно. Хочется железобетонной надёжности, то можно использовать (MS-)DOS.

          • powerman
            /#21336556

            Автомобили, в отличие от лошадей, давали явные преимущества всем и каждому. А IPv6, как Вы сами верно заметили в начале комментария, это "ненужность провайдерам и конечным пользователям". Стоимость оборудования за это время изменилась, а вот насчёт ненужности — всё по-прежнему актуально, даже не смотря на то, что IPv4 совсем-совсем кончились.

            • stargrave2
              /#21336578

              Вы перевираете. Я говорил про ненужность Интернета как такового для пользователей (и обеспечения Интернетом провайдерам этих пользователей, следовательно). А для Интернета очевидно что жизни без IPv6 нет. Сейчас оборудование уже и заменилось за столько лет и уже давно поддерживает IPv6. Именно поэтому мы видим, не смотря на мою убеждённость что людям Интернет не нужен, что больше половины трафика в США идёт по IPv6, что больше половины людей там, в Великобритании и в Германии у крупных операторов, имеют IPv6.

              • powerman
                /#21336596

                Они все имеют IPv6 просто потому, что ISP им его выдаёт по умолчанию, их OS его поддерживает по умолчанию, и трафик возникает потому, что ютуб им по умолчанию выдаёт AAAA запись.


                Сами пользователи в Интернете и IPv6 по-прежнему не нуждаются, ничего про него не знают, и не подозревают о том, что вся эта выдача им IPv6 "по умолчанию" ослабляет их безопасность.


                Я к тому, что объёмы трафика тут не показатель. Показателем свершившегося внедрения IPv6 станет исключительно точка, в которой у обычных пользователей не получится по IPv4 заходить на часть нужных им и достаточно популярных сайтов. А такого может ещё лет 20 не случиться.

                • stargrave2
                  /#21336606

                  Лично у меня полно личных ресурсов/серверов где только по IPv6 можно попасть. Да и блоги людей я знаю которые доступны только по IPv6. Сейчас сложнее найти ресурсы которые бы *не* были доступны по IPv6 (к сожалению, удивительно, но до сих пор остаются ещё такие, тот же Хабр :-)).

                  • edo1h
                    /#21336658

                    Сейчас сложнее найти ресурсы которые бы не были доступны по IPv6

                    взял alexa top 50, скормил dig -t aaaa, оказалось 12 сайтов из списка имеют ipv6 адреса

                    • stargrave2
                      /#21336704

                      YouTube, всё что у Google, Facebook, VK, Yandex, Instagram — всё на IPv6 (многое уже как лет 10).

                      • none7
                        /#21339002

                        VK IPv6 не осилил и давно уже AAAA записей не отдаёт. Основные скрипты работали как положено, а выдача статики и скрипты на сторонних сайтах падали.

                  • andreymal
                    /#21336700 / +2

                    ВК когда-то имел IPv6, но через некоторое время его отключили. По заверениям поддержки, из-за спамеров. (В чём связь между спамерами и IPv6, объяснять отказались)

                    • stargrave2
                      /#21336706

                      Ого, ничего себе! А я ведь застал время когда ВК был полностью IPv6. Про такое слышу впервые, что от IPv6 избавляются :-)

      • a1888877
        /#21336640

        Я обрезал цитаты, что бы сократить текст:

        Он не может заменить из-за инертности мышления людей

        Ближайший аналог — 2G/3G/4G. Инертность мышления не мешала переходу.
        Отсутствие Интернета означает повышенную безопасность. Отключите кабель — будет ещё безопаснее

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

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

        Да, как всегда, когда жадность потребителей мешает оплатить белый адрес. А производителей железа внедрить протокол без дефицита адресов.
        Зависит от IKE демонов

        Да. С этим хорошо в последних Linux. А вот варианты Windows-Linux-Cisco-Android и IPSec вызывают сильное неприятие всё этой радости. Изначальный IPSec имел не особо набор не особо стойких алгоритмов типа DES и кучу CVE в его разных реализациях.
        Да, и все NDP/MIPv6 и прочие заточены под то, что всё может меняться.

        Я писал, что ваша идея из статьи использовать вместо site-local глобальные префиксы, которые сменятся при смене провайдера — не очень практичная.
        Это просто короткий и запоминающийся адрес.

        Он сложней 4-х трехзначных цифр. И сложность человеку работать с адресами — объективная проблема IPv6. И возможности сокращения, демонстрируемые в статья плохо релевантны адресациям в реальных сетях — я на свой ближайшей сервер зашел, там префикс 2a03:b0c0:3:d0::27b:e009, это ну никак не «достаточно короткие и легко запоминающиеся».
        классовая адресация крайне нерационально использовала пространство

        В IPv6 я вижу повтор этой истории.
        Про Windows не знаю. Но вот вне Windows как-то не прижилось.

        Это живой пример, что link-local не завязаны на сетевой протокол. Можно было сделать отдельный, независящей от IPv4 и IPv6 протокол и внедрить в разных ОС.
        любят даже ICMP полностью блокировать

        Это результат эволюции и всевозможных атак из 90-х. Поэтому и странно видеть, как ICMPv6 пытается повторить похожий путь.
        Не понял причём тут какой-то 192.168.1.1, SLAAC и DHCP.

        Для обывателя SLAAC не привносит ничего нового — он не заметить разницы.
        Это явно не соответствует действительности. Я даже не знаю откуда такое вы взяли или увидели.

        RFC3513. Но ОК, новый RFC4291 это ограничение снял.
        Решения о маршрутизации принимаются на основе фиксированного заголовка

        Сейчас, в IPv4 это работает так же.
        На самом деле они 128 битные

        Уже нет. Это сломает маршрутизацию. Железо из Tier 1 ради оптимизаций все, что ниже /64 маршрутизировать не будет ибо не реализовано. SOHO сегмент не может из-за совместимости с RA/DHCPv6 и текущими реализациями стеков. Адреса, как бы теоретически, 128-битные, но только маршрутизировать из них больше 64 уже не выйдет.
        Ну не половина, а 48-бит

        Я может запамятовал, но на вскидку из 48 бит MAC генерировалось 64 нижней части. Ну или уже не так помню и тяжко лезть в RFC искать.
        в идеале он должен быть point-to-point без ненужного overhead-а от адресов канального уровня.

        Штуки вроде NDP говорят об обратном. Выдавать по local-link IPv6 каждому порту коммутатора в ЦОДах тоже никто вроде не предлагает. А Ethernet/WiFi преобладают безальтернативно и рассчитывать IPv6 под другой канальный уровень странно. Поэтому идеи о ptp как оправдание такой схемы адресации выглядят странно.
        Проблемы и мысли людей делающих подобное не стоит мешать с теми, кто продумывал IPv6 протокол.

        Это то, во что IPv6 эволюционировал. Текущее положение дел. Исправление и свидетельство ошибок тех, кто придумывал IPv6. Я не понимаю, почему вы думаете, что пришли какие-то левые люди и начали штамповать похабные RFC ломающие замысел первоначальных авторов.
        Не всегда стоит нести совместимость с чем-то предыдущим.

        Цена должна быть оправдана. ~24 года с создания IPv6, ~40 с создания IPv4. И протокол никак не рассчитанный под современную сеть менять не хотят. У нас в компании думали внедрять IPv6 ещё лет 7 назад, с регистрацией своих префиксов и т.д., но из-за отсутствия совместимости Dual Stack в те времена отставили IPv4. И всё, внедрение не состоялось.

        • stargrave2
          /#21336694

          >Ближайший аналог — 2G/3G/4G. Инертность мышления не мешала переходу.

          Они не так отличаются по сути работы своей.

          >Вообще да, с отключенным кабелем действительно будет ещё безопаснее. Отсутствие полной симметричной связанности мешает лично вам, но для большинства потребителей интернета — эта плюс.

          Не стоит их называть потребителями Интернета. Это потребители удалённых сервисов. Поднять IPsec между компьютерами они не смогут — какой же тут Интернет?

          >NAT нужен

          Единственное для чего он был нужен — как-то выжить в условиях нехватки IP адресов. На этом всём.

          >Благодаря NAT, можно полностью переделать сегмент сети, с заменой сервисов в ней, протестировать всё это, в том числе на части живых пользователей и выкатить в прод незаметно для пользователей одной командой в консоли маршрутизатора. И в таких задачах у NAT замены нет.

          Это решается маршрутизацией.

          >Да. С этим хорошо в последних Linux. А вот варианты Windows-Linux-Cisco-Android и IPSec вызывают сильное неприятие всё этой радости. Изначальный IPSec имел не особо набор не особо стойких алгоритмов типа DES и кучу CVE в его разных реализациях.

          Microsoft всегда в своём духе.

          >Я писал, что ваша идея из статьи использовать вместо site-local глобальные префиксы, которые сменятся при смене провайдера — не очень практичная.

          Ваша идея использовать site-local адреса, без очень веских на то причин (они могут быть, не спорю, просто не верю что часто), гарантированно вызовет геморрой при коллизии сетей объединённых VPN-ом.

          >Он сложней 4-х трехзначных цифр. И сложность человеку работать с адресами — объективная проблема IPv6.

          Это ваше субъективное мнение. Наверное мозг людей по разному устроен. Но мне абсолютно несвязанные 4 десятичных числа не просто запомнить, вот честно, правда.

          >В IPv6 я вижу повтор этой истории.

          Где-то есть опасения что адресов уже начало не хватать?

          >Это живой пример, что link-local не завязаны на сетевой протокол. Можно было сделать отдельный, независящей от IPv4 и IPv6 протокол и внедрить в разных ОС.

          Ну вот за столько десятков лет IPv4 так ничего подобного и не сделали чтобы везде было и работало. IPv6 сделал.

          >Это результат эволюции и всевозможных атак из 90-х. Поэтому и странно видеть, как ICMPv6 пытается повторить похожий путь.

          Мне то странно видеть что вы её кладёте на этот путь. По вашей логике вообще не нужно ничего нового изобретать и писать новый софт. Нет, я тоже в целом приверженец идеи «работает — не трожь» и противник «движения ради движения» (кто-то считает прогрессом ради прогресса), но всему есть разумные пределы применимости. Видеохостинг изначально можно поднять на одном сервере с хранением видео файлов на ФС как есть. Но с ростом популярности такого сервера, придётся делать системы как в ivi.ru, где работают сотни программистов и сетевых инженеров. IPv4 уже не удовлетворяет потребностям.

          >Для обывателя SLAAC не привносит ничего нового — он не заметить разницы.

          Обывателю достаточно оставить с дюжину сайтов типа YouTube, VK, FB, и т.д., а всё остальное отрубить — я уверен что 99% не заметят разницы тоже. Обыватели меня не интересуют.

          >Решения о маршрутизации принимаются на основе фиксированного заголовка
          >Сейчас, в IPv4 это работает так же.

          Только заголовок обрабатывается сложнее (разная длина, плюс пересчёт checksum на каждом hop). А так да: в IPv6 аналогично, просто проще.

          >Уже нет. Это сломает маршрутизацию. Железо из Tier 1 ради оптимизаций все, что ниже /64 маршрутизировать не будет ибо не реализовано. SOHO сегмент не может из-за совместимости с RA/DHCPv6 и текущими реализациями стеков. Адреса, как бы теоретически, 128-битные, но только маршрутизировать из них больше 64 уже не выйдет.

          Вы придумываете. Когда у меня был /64, то я дробил на маленькие сети, между разными устройствами (FreeBSD машины). Про Tier1 ничего не скажу, но ok, там поверю что ради оптимизации они не смотрят на 64-бит. Там это крайний случай.

          >Я может запамятовал, но на вскидку из 48 бит MAC генерировалось 64 нижней части. Ну или уже не так помню и тяжко лезть в RFC искать.

          48 бит становятся 64 битами, да. Просто энтропии в этом адресе всё-равно 48 бит. Плюс два байта константы вставляются.

          >Штуки вроде NDP говорят об обратном. Выдавать по local-link IPv6 каждому порту коммутатора в ЦОДах тоже никто вроде не предлагает. А Ethernet/WiFi преобладают безальтернативно и рассчитывать IPv6 под другой канальный уровень странно. Поэтому идеи о ptp как оправдание такой схемы адресации выглядят странно.

          NDP как-раз говорит о том, что он адреса канального уровня явно может и не быть — поэтому поля переносящие *внутри* ICMPv6 link-layer адрес: опциональны. На самом деле отличная apenwarr.ca/log/20170810 статья как-раз и предлагает делать на каждом порте коммутатора IPv6 сеть сразу же. По сути же оно так уже и есть: у нас точка-точка соединения чисто физически.

          >Это то, во что IPv6 эволюционировал.

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

          >Я не понимаю, почему вы думаете, что пришли какие-то левые люди и начали штамповать похабные RFC ломающие замысел первоначальных авторов.

          Ну… потому что вот прям буквально так и думаю, действительно. Я программист и прекрасно знаю что можно делать костыли побыстрее, решая сиюминутные задачи. А можно хорошо что-то продумывать, просто сложнее и дольше внедрять потом придётся. Сколько коммитетов/разработчиков — столько и подходов может быть. Все они профессионалы, бесспорно, но я сам, будучи разработчиком, не со всеми разработчиками согласен в решениях. Текущая статья: полная солидарность с разработчиками IPv6/NDP/MIPv6/и т.д…

          >Цена должна быть оправдана. ~24 года с создания IPv6, ~40 с создания IPv4. И протокол никак не рассчитанный под современную сеть менять не хотят. У нас в компании думали внедрять IPv6 ещё лет 7 назад, с регистрацией своих префиксов и т.д., но из-за отсутствия совместимости Dual Stack в те времена отставили IPv4. И всё, внедрение не состоялось.

          Ну а в США больше половины трафика это IPv6 *уже*. Можно и дальше бесконечно вспоминать старые времена как оно не получилось. 7 лет назад SLAAC-RDNSS мало кто поддерживал, сводя на нет его как возможную замену DHCP. Я IPv6 пользуюсь уже 10+ лет, но только сейчас вот написал про него статью, только сейчас считаю что пора.

          • a1888877
            /#21336906

            2G/3G/4G:

            Они не так отличаются по сути работы своей.

            Между ними лежит пропасть сильно большая, чем между IPv4 и IPv6.
            Единственное для чего он был нужен — как-то выжить в условиях нехватки IP адресов. На этом всём.

            То, что лично вам NAT чем-то мешает не делает его автоматически не нужным. Я уже дважды писал для чего он требуется. И насчет всех этих идей про «выживание при нехватке IP адресов» – изначально NAT работал 1 к 1. А серые IP (нынешний NAT) назывались PAT и появились сильно позже. Поэтому NAT ортоганален нехватке адресов и вообще не для нее создан был.
            Это решается маршрутизацией.

            Для некоторых конфигураций, тот же результат можно получить через маршрутизацию. Но, только вы вообще представляете себе какую конфигурацию нужно наворотить для полноценной Anycast маршрутизации эквивалентной NAT-у? Я вот на вскидку знаю пару человек, которые за пол дня смогут сделать тоже самое, что за пару минут делается 2-3 строчками через NAT. И уж молчу про дополнительное оборудование и ценник на него.
            Ваша идея использовать site-local адреса, без очень веских на то причин (они могут быть, не спорю, просто не верю что часто), гарантированно вызовет геморрой при коллизии сетей объединённых VPN-ом.

            Что неожиданно легко решается NAT-ом. Зато ваша идея убьет сеть при смене провайдера.
            Это ваше субъективное мнение. Наверное мозг людей по разному устроен. Но мне абсолютно несвязанные 4 десятичных числа не просто запомнить, вот честно, правда.

            Тоже цифры, также несвязанные, только шестнадцатеричные и больше.
            Ну вот за столько десятков лет IPv4 так ничего подобного и не сделали чтобы везде было и работало. IPv6 сделал.

            Microsoft сделал. На Linux серверах такой проблемы вообще нет. Даже для Linux клиентов есть свои аналоги вроде zeroconf & etc.
            Мне то странно видеть что вы её кладёте на этот путь. По вашей логике вообще не нужно ничего нового изобретать и писать новый софт.

            Но я же и возмущаюсь, тем, что ICMPv6 здесь не привнес ничего нового, а повторил сделанное и в дальнейшем отвергнутое в IPv4/ICMP. Просто лет через 10 будут блочить уже ICMPv6 и всё.
            Обыватели меня не интересуют.

            Но у вас популистская статья, для обывателей. Не техническое сравнение, не примеры ваших кейсов и настроек — а ведь по комментариям видно, что у вас хорошо заработала связка IPv6 + IPSec для развертывания своих AutoConf сетей поверх интернета. Опиши вы её часть народа ломанулась бы повторять – вот вам и способствование внедрению IPv6.
            Только заголовок обрабатывается сложнее (разная длина, плюс пересчёт checksum на каждом hop). А так да: в IPv6 аналогично, просто проще.

            Я просто не знаю откуда вы это взяли…. Какая разница какая длина, если смещение адресов от начала пакета одинаковое? Для маршрутизации IPv4 лучше IPv6 из-за более коротких адресов для простых маршрутизаторов, а IPv6 лучше IPv4 из-за пока сильно менее раздутого числа маршрутов для Full View маршрутизаторов.
            Вы придумываете.

            Проблема не во FreeBSD, а в «альтернативных» стеках. Всякий IoT, роутеры, IP камеры и т.д., одно такое устройство, в котором одаренный программист не выполнил RFC (а у IPSec их здоровая куча) и всё – ваша дробленая сеть со сложной маршрутизацией с этим устройством работать не будет. А во всех этих девайсах лютый треш бывает.
            На самом деле отличная apenwarr.ca/log/20170810 статья как-раз и предлагает делать на каждом порте коммутатора IPv6 сеть сразу же.

            Статья ИМХО весьма противоречивая. Такое интересный идеализм игнорирующий и физическое устройство коммутаторов и смысл SDN-на и местами здравый смысл. Но реально слишком много — там целую статью писать можно в ответ.
            IPv6 это RFC описывающие IPv6. Плюс NDP. Плюс ещё несколько. Не нужно приплетать странные (дурные) RFC ко всей кучи и считать что их или кто-то обязан реализовывать или хотя бы даже прислушиваться. Эти дурные вещи никто никуда не тащит, в здравом уме.

            Зачем это куда-то тащить? И Windows и Linux исполняют RFC 7217, а до этого RFC 4941, которые как вы наивно думаете являются «странными (дурными)».
            Ну… потому что вот прям буквально так и думаю, действительно.

            Но я же говорю не об каких-то абстрактных материях – это то, что реализовано в операционных системах ещё со времен Windows XP. Да и как-бы конгломерат RFC описывающих IPv6 – эта здоровая куча из десятков взаимосвязанных документов, по несколько на все эти SLAAC, RA, DHCPv6, Address Architecture и т.д.

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

            • stargrave2
              /#21336968

              >Между ними лежит пропасть сильно большая, чем между IPv4 и IPv6.

              Ваше субъективное мнение.

              >То, что лично вам NAT чем-то мешает не делает его автоматически не нужным.

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

              >Что неожиданно легко решается NAT-ом.

              Все ваши доводы по поводу NAT-а для меня выглядят абсолютно безумно нерациональностью. Вы представляете тяжеловесность NAT-а? Ну, в принципе что это за технология, как устроена? Очевидно что да. С таким же успехом, можно предлагать всё делать на прикладном уровне. Ну например HAProxy/nginx-ы разбирающие и балансирующие (или что там понадобится) HTTP запросы. Бывают места где без этого просто никак. А есть места где это сделать и просто, только крайне не эффективно с точки зрения ресурсов компьютеров. NAT относится к последнему. Просто все описанные вами usecase-ы, как их на лету подключать/отключать, меня конфигурацию и прочее — вовсю и по полной делается в ivi.ru, где я когда-то работал (не над сетями): о NAT-ах речи просто не может идти, когда трафик в сотни гигабит несколько лет назад был. Вопрос не в том что можно или нет решить эти задачи NAT-ом, а эффективно ли это или нет. Большинству людей просто поставить NAT на домашнем маршрутизаторе, чем писать правила firewall-а. Молоток предназначен для забивания гвоздей, а ещё им можно двери подпирать — это не значит что им стоит подпирать двери, если конечно он всё-равно при этом постоянно и для забивания гвоздей используется. В IPv6 мире, считайте, исчезла задача забивания гвоздей — молотку не место.

              >Microsoft сделал. На Linux серверах такой проблемы вообще нет. Даже для Linux клиентов есть свои аналоги вроде zeroconf & etc.

              Только из коробки эти zeroconf мало в каких дистрибутивах идут.

              >Но я же и возмущаюсь, тем, что ICMPv6 здесь не привнес ничего нового, а повторил сделанное и в дальнейшем отвергнутое в IPv4/ICMP.

              Ну, тут я и остановлюсь пожалуй, ибо в RFC NDP (одного только NDP!), раз в моей статье этого не видно, не одна страница сравнения с IPv4 и сколько он нового привнёс. Если не замечать и всего остального в таком же масштабе…

              • netch80
                /#21338222

                > Штука которая делает неработоспособными любой протокол про который её явно не обучили? Какой бы костыль не был, но лучше без костылей.

                И чем это отличается от того, что вы будете иметь без NAT?
                Пусть у вас внутренняя сеть на мировых адресах, выданных из провайдерского /48, и вам протокол по каким-то причинам предлагает у клиента открыть порт и принимать на него соединения извне. Вы будете пускать всех, кто знает IP конкретного клиента? Спасибо, админ, предложивший такое, будет уволен за глупость и нулевые знания в области безопасности. Значит, файрволл по какому-то условию (клиент его оповестил, что есть внутри порт, или изнутри начали стучаться)? Тогда нет разницы с тем, что в случае NAT: за счёт граничного файрволла — протокол не работает.

                Покажите мне, как вы будете решать эту проблему в случае вашего тотального IPv6 и без открытия внутренней сети всем мировым ветрам на вход. Покажете надёжный метод — ok, можно будет поверить, что это лучше NAT. Пока что сколько я ни спрашивал апологетов IPv6, мне никто на это не смог ответить.

                На практике же в результате вместо, например, SIP — для которого задача пропустить медиапоток за NAT требует костылей вроде промежуточных прокси, STUN-серверов, ICE и т.п. — используют IAX2, у которого всё бегает по одной UDP ассоциации. Вместо FTP, с проблемами активного режима, массово используют HTTP. И так далее. И с таким уже нет разницы, NAT или не NAT, главное, что диверсанты снаружи внутрь не проходят.

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

                Подробности в студию — как это по-вашему делается «на прикладном уровне». Один метод — завернуть всё в одно соединение (ассоциацию) я уже описал. Есть другие предложения?

                > В IPv6 мире, считайте, исчезла задача забивания гвоздей — молотку не место.

                Всё те же проблемы в том же виде.

              • alliumnsk
                /#21352862

                Из этой поста, злоупотребляющем полужирным выделением и словами-лозунгами, создается впечателение, что молоток здесь именно как ipv6

            • edo1h
              /#21337030

              а IPv6 лучше IPv4 из-за пока сильно менее раздутого числа маршрутов для Full View маршрутизаторов.

              вы ошибаетесь, записей уже не меньше (то есть сам fw уже заметно толще). а если и правда каждая фирма будет брать себе as, то вообще коллапс настанет.

      • sumanai
        /#21341740 / +1

        Это явно не соответствует правде. Нигде не встречал чтобы выдавали меньше.

        У меня уже второй хостер выдаёт IPv6 поштучно за деньги.

    • netch80
      /#21338258

      > Плюс 128 битные адреса, которые на самом деле 64 битные, поскольку последние 8 байт генерирует EUI из MAC адреса устройства. Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско.

      Когда его задумывали, предполагалась при этом и замена MAC адресов напрямую IPv6 адресами с отменой ARP. Можно поискать — например, по публикациям Radia Perlman (много агитировала за упрощение L2/L3 взаимодействия). Но на Ethernet это не состоялось. Состоялось только на Infiniband — там 16-байтный адрес формируется из GUID адаптера (это как MAC, но 8-байтный) стандартным link-local IPv6 префиксом.

      > Удивительно, как имея IPv4 — далеко не идеальный и не беспроблемный протокол, десять лет его эксплуатации в живых сетях и решения проявившихся проблем можно было создать IPv6.

      А они не думали толком. IPv6 стабилизировался в базовых спецификациях ещё до того, как IPv4 CIDR начал массово распространяться. Но отменять поспешные решения никто уже не хотел.

      В 1994-м (год окончательного принятия 128 бит) шли шатания в предложениях; было одновременно 64 и 128, причём 128 вначале состояли из двух разных уникальных адресов (!) — 64 на глобально уникальный и 64 на локально уникальный. Окончательным аргументом в пользу 128 стало письмо:

      ==={{{ <9407072035.aa15952@sundance.itd.nrl.navy.mil>

      Yes, you said the magic words, «FIXED LENGTH.» I have espoused the virtues
      of fixed length addresses before. My biggest beef with variable length
      addresses is the issue of maintaining additional state or taking additional
      time to parse an address whose length I don't know at the start.
      [...]
      > 8 byte fixed length address.

      I have no problem with this, but this alienates many people. Also, there
      seems to be a trend toward low percentage of allocated address space used.
      (I offer NRL itself as an example, though not the worst, of such waste.)

      If we could pull it off with 8 bytes, I'd be all behind it.

      > 16 byte fixed length address.

      This eliminates much alienation. Furthermore, wasted address space is not
      a significant problem here.
      [...]
      My position can be best summarized as:

      The SMALLEST possible fixed-length address. And that length
      better have a good justification for why it cannot be smaller.

      ===}}}

      Источник: ftp.sayclub.com/pub/ietf/concluded-wg-ietf-mail-archive/sipp/1994-07

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

  14. roller
    /#21336850 / +1

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

    • stargrave2
      /#21336964

      2020-ый год, а люди считают что можно выходить в Интернет без firewall…

      • edo1h
        /#21337010

        А почему нельзя? Говорят, что даже винду сейчас со встроенным файерволом можно выставлять, не пробовал. Линуксовых хостов с реальными ip и пустыми iptables есть у меня в достаточном количестве.

        • roller
          /#21337038

          Если у вас ss -lnt пустой (ну или только ssh) то вам и iptables не нужен.

        • edo1h
          /#21337040

          хотя, конечно, я понял про что вы, просто поёрничать захотелось.


          мне в этом споре сторонников выхода локалки через nat и сторонников файервола на роутере вообще непонятен предмет спора. по сути это одно и то же же, в linux используются одни и те же таблицы conntrack, настраивается через тот же самый iptables (или что там сейчас модно? nftables?)
          заметной разницы с точки зрения настройки, внутреннего устройства и безопасности всего этого ИМХО нет.


          только nat таки нужен, так что и в ipv6-only сетях он иногда будет встречаться (и вы вроде бы уже согласились с этим).

      • le1ic
        /#21338232

        защита должна быть эшелонированной

  15. ivlad
    /#21337666

    Мне кажется, в 2020 году эта проповедь смысла не имеет.


    Примерно все, кто хотел разобраться в IPv6, уже разбираются. Мировое проникновение на клиентской стороне сейчас находится между 25% и 30% и продолжает рости. Поддержка на стороне софта не повсеместная, но достаточно массовая. Будут, конечно, какие-то странные личности, которые до последнего станут цепляться за IPv4 и это будет продолжаться ещё долго, но прогресс неостановим.


    Странные личности — это повод для шуток, я встречался в 2001 году с людьми, которые на полном серьёзе говорили, что Ethernet скоро отомрёт и все перейдут на TokenRing. Примерно также можно относиться к апологетам тезиса "NAT is a security feature".


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

    • powerman
      /#21338786

      NAT сам по себе не является security feature. Но существование NAT и самого понятия "локалка" в 2020 отрицать столь же бессмысленно, как отрицать сам IPv6. Является NAT вселенским злом или нет — не суть важно, важно другое: из-за NAT все уже привыкли к тому, что безопасность внутри локалки можно поддерживать на уровне сильно ниже того, который необходимо поддерживать для доступных извне узлов. И сегодня бессмысленно давать этому оценку — хорошо это или плохо, корректно такое отношение или нет — потому что факт в том, что устройства и сервисы в локалке зачастую абсолютно ничем не защищены — ни файрволами, ни аутентификацией (либо аутентификация там уровня admin:admin).


      Открывать ко всем этим устройствам и сервисам прямой доступ из внешнего интернета в текущих реалиях — безумие (что подтверждается недавними громкими атаками, когда JS в браузере юзера использовался для сканирования и атаки сервисов в локалке или на localhost). Обеспечить перенастройку локальных сервисов под стандарты безопасности внешних — даже не знаю, реально ли это в принципе (в мелких компаниях нередко используется в т.ч. самописный софт, в котором аутентификацию никто даже не предусматривал, потому что он же "только для своих" — его переделывание, учитывая что разработчик уже много лет тут не работает, а исходники потеряли… в общем это может оказаться похлеще проблемы 2000 и перехода на 64-битные процы вместе взятых). И даже если это реально — кто этим всем будет заниматься, и будет ли кто-то заниматься в принципе? И сколько времени на это уйдёт? В каждой SOHO локалке? Там обычно просто нет достаточно квалифицированных спецов для этой работы, равно как и нет понимания необходимости в этих изменениях.


      Даже в этом треде отписалось несколько человек, которые пытались у себя внедрять IPv6 по собственной инициативе, и потом от него отказались, в т.ч. из соображений безопасности. Угадайте, что случится, когда в SOHO массово заработает IPv6, и следом их пойдут массово взламывать? Первым делом все они отключат IPv6, потому что с одной стороны будет паника, а с другой нет другого быстрого и дешёвого способа вернуть старый уровень безопасности для локалок. И уговорить их снова его включить может оказаться не так просто, как в первый раз.

      • Tolmy
        /#21338916

        Угадайте, что случится, когда в SOHO массово заработает IPv6, и следом их пойдут массово взламывать? Первым делом все они отключат IPv6, потому что с одной стороны будет паника, а с другой нет другого быстрого и дешёвого способа вернуть старый уровень безопасности для локалок. И уговорить их снова его включить может оказаться не так просто, как в первый раз.

        IPv6 уже массово заработал в SOHO. В практически любом месте в смартфоне в США по умолчанию будет включен IPv6. Более того, особо упоротые мобильные операторы грозятся в ближайшем будущем отключать IPv4 по умолчанию и включать его только по явному требованию пользователя. Аналогично дела обстоят и с кабельным доступом.
        Я админю некоторое количество серверов в США и веб-серверов в том числе, и это крупная международная компания. Не IT. Вот, полез проверил, у них на сайте примерно 60% запросов — из IPv6.
        Что-то это не вызывает никакой паники.

        • powerman
          /#21339354

          Паника будет, когда его начнут массово ломать. А взлом дело такое, он работает от цены — как только текущими методами станет слишком дорого ломать, так сразу и переключатся на альтернативные методы, включая активное использование IPv6. Те же дыры в процах существовали лет 15, если не больше, и никому до них не было дела — пока были более дешёвые способы ломать. Аналогично будет и с IPv6 — чем больше вокруг IPv6 и чем лучше защищены системы на IPv4 — тем выше шанс, что начнутся массовые атаки на IPv6. Просто это случится ещё не сегодня, и даже не завтра. Но через 3-4 года — запросто.

      • ivlad
        /#21340292

        Но существование NAT и самого понятия "локалка" в 2020 отрицать столь же бессмысленно, как отрицать сам IPv6.

        Ну, где-то бесмысленно, а где-то — осмысленно. Гугл вот в своём Beyond Corp отрицает и ничего. Я тоже отрицаю для достаточно больших организаций. Для SOHO — не отрицаю.


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

        "все" — это слишком сильное утверждение. Не все. Большие компании не привыкли. SOHO, наверное, да, в этих терминах думают. Это неважно, потому, что SOHO маршрутизаторы по умолчанию точно так же запрещают подключение извне к устройствам внутри. Вот у меня сейчас адрес 2401:7400:c802:16e3:4867:450c:79d5:4932 — пингуется, а подключиться к netcat, который слушает на порту 31337 снаружи не получается, маршрутизатор дропает пакеты. Можете попробовать. И NAT тут вообще не при чём.


        Даже в этом треде отписалось несколько человек, которые пытались у себя внедрять IPv6 по собственной инициативе, и потом от него отказались, в т.ч. из соображений безопасности.

        Я думаю, они плохо понимают безопасность в сетях IPv6.


        Еще, кажется, есть люди, которые ненавидят то, что не понимают. Это, конечно, нормально, но слушать их не надо.

        • powerman
          /#21341702

          Я написал: переход на IPv6 прямо сейчас сильно снизит безопасность SOHO; плюс многие из тех, кто в состоянии безопасно настроить IPv4, не готовы выделить достаточно много времени чтобы сделать то же самое для IPv6, потому что это значительно сложнее.


          Вы ответили: IPv6 можно настроить безопасно если иметь достаточную квалификацию.


          Поговорили, в общем.

    • Tolmy
      /#21339070

      Как только гугл закончит свою бессмысленную войну за хороший https и против гадкого http, вполне может оказаться, что следующей причиной для изменения рейтингов выдачи сайтов будет наличие AAAA записи в DNS. А однажды — отсутствие A записи в DNS ;)
      И тогда все те, что горой стоят против внедрения IPv6, молча козырнут и бегом начнут переводить все свои сервисы на IPv6. А пока всё и так работает — "работает? Ничего не трогай!" (с)

    • edo1h
      /#21339184

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

      вот вы сами и констатировали, что никому этот ipv6 не нужен

      • ivlad
        /#21340294

        Не нужен, не нужен, не переживайте. TokenRing вот-вот победит.

        • edo1h
          /#21341230

          ага. я насмотрелся уже на любителей бежать впереди паровоза, например провайдер построил сеть на atm, который "вот-вот победит", в результате сеть сейчас перестроена на ethernet, сколько денег было вбухано впустую — страшно представить.
          и таких примеров несть числа — infiniband, itanium, rdram, …


          да, я немного передёргиваю, ipv6 взлетит. когда-нибудь. но пока большинство провайдеров ip4-only — о чём говорить?

  16. gxcreator
    /#21337822

    На самом деле все это очень круто выглядит на бумаге, а на деле нужны всякие temp-адреса для секурности, т.к. хз как вообще решать проблему что провайдер, сайты и все на пути видят(=собирают данные) идентификаторы устройств.
    Еще на практике сразу же прилетают другие грабли — чтобы работал SLAAC надо емнип чтобы провайдер выдавал /48 минимум, а это далеко не все провайдеры делают. Т.е. из-за SLAAC получается что деление на подсети прибито гвоздями RFC. Так и получаются всякие уродливые костыли типа NAT66.
    Еще не совсем понятно как правильно организовывать зоны RLOC — тут тоже есть разночтения(например в 6LoWPAN).

    • ivlad
      /#21338198

      Для SLAAC нужно /64. RFC 4941 по-моему по умолчанию включено на популярных клиентских OS.


      Не понял, как SLAAC связан с NAT66. И причём тут RLOC — тоже не понял.

      • gxcreator
        /#21338624

        Ну по сути провайдер должен давать больше чем /64, из RFC7084:

        L-2: The IPv6 CE router MUST assign a separate /64 from its
        delegated prefix(es) (and ULA prefix if configured to provide
        ULA addressing) for each of its LAN interfaces.

        WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating
        router the size of the prefix it requires. If so, it MUST
        ask for a prefix large enough to assign one /64 for each of
        its interfaces, rounded up to the nearest nibble, and SHOULD
        be configurable to ask for more.


        Не понял, как SLAAC связан с NAT66

        Из-за того, что провадер дает меньше /64(некоторые дают вообще один адрес или /16), на помощь приходят всякие костыли типа NAT66.

        И причём тут RLOC — тоже не понял.

        Это не по теме SLAAC, но некоторые стандарты, которые основаны на IPv6 RFC, по разному определяют Realm Local.

        • ivlad
          /#21340398

          The IPv6 CE router MUST assign a separate /64 from its delegated prefix(es) (and ULA prefix if configured to provide ULA addressing) for each of its LAN interfaces.

          Это же не про провайдера, это про то, что маршрутизатор должен назначать /64 на каждый свой внутренний интерфейс. Да, разумеется, должен.


          Из-за того, что провадер дает меньше /64(некоторые дают вообще один адрес или /16), на помощь приходят всякие костыли типа NAT66.

          А, вы говорите, что есть провайдеры, которые нарушают RIPE-690. Да, наверное, есть. Это тоже происходит от непонимания того, как IPv6 работает.


          Теперь я понял, кажется, о чём это:


          Еще на практике сразу же прилетают другие грабли — чтобы работал SLAAC надо емнип чтобы провайдер выдавал /48 минимум, а это далеко не все провайдеры делают.

          Вот BCP, на который я сослался, говорит "/48 каждому или /48 бизнесам, /56 SOHO". Провайдеры, которые так не делают, творят дичь, но, к сожалению, никто не может им этого запретить. Я видел на провайдерском форуме как-то "выдадим /64 на район". Это не проблема IPv6, это проблема в недостаточной технической грамотности этих провайдеров.

  17. alliumnsk
    /#21338506

    Не так давно считал плотность адресов ipv4 по бесплатному набору данных от ip2location.com.
    Карта:
    https://alliumnsk.netlify.com/images/gradientm.png

    ipv4 адреса распределены сильно неравнмерно. В китае ~4 человек на 1 айпи4 адрес, а в Канаде ~2.5 адреса на человека
    p.s. благодаря написанию этого комментария осознал ошибку у себя


    можно глупый вопрос? А ipv6 как-нибудь решит проблему того, что траффик, скажем из Сибири до Японии идет не напрямую, а через Москву, Западную Европу (опциально США) и только потом в Японию?

    • Tolmy
      /#21338926

      А ipv6 как-нибудь решит проблему того, что траффик, скажем из Сибири до Японии идет не напрямую, а через Москву, Западную Европу (опциально США) и только потом в Японию?

      Нет конечно. Это две ортогональных сущности, роутинг и адресация.

      • alliumnsk
        /#21342234

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

        • Tolmy
          /#21351064

          Нет, вот не нужно смешивать адресацию, маршрутизацию и ещё и географические координаты. Вот вообще не нужно, даже руководствуясь благими намерениями. Потому что вот прямо сейчас у меня на компе адреса, принадлежащие польскому и американскому провайдеру. Гугл, к примеру, считает, что я в США нахожусь. Потому что маршрут ко мне именно так и выглядит. И я лично хочу, чтобы так и продолжалось и впредь.

          • alliumnsk
            /#21352952

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

            • Tolmy
              /#21354324

              Нет, я совсем про другое. Про то, что пути роутинга неисповедимы и маршрут между двумя соседними домами на одной улице запросто может проходить через Варшаву, Ганновер и Хельсинки. И это правильно, не надо это ломать. Даже из благих побуждений.
              Из этого следует прямой вывод, что географические координаты в адресе — бессмысленны. Адрес, он для машин, а не для людей, а раз географические координаты в адресе машинам не нужны, то и толкать их туда не надо.

              • alliumnsk
                /#21354674

                Про то, что пути роутинга неисповедимы

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


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


                а раз географические координаты в адресе машинам не нужны, то и толкать их туда не надо.
                Да мне без разницы, каким способом, просто я хочу, чтобы скажем, у меня пинг до Кореи был не 500 мс, а хотя бы 90.

                (Автор статьи, кстати, предлагал пихать в адрес человеко-читаемые рюшечки, по сути дублирующие DNS)

                • Tolmy
                  /#21354986

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

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


                  Да мне без разницы, каким способом, просто я хочу, чтобы скажем, у меня пинг до Кореи был не 500 мс, а хотя бы 90.

                  И как этому может помочь впендюривание географических координат в IP адрес?
                  Универсальный совет, хотите небольшой пинг до XYZ — езжайте жить поближе к XYZ и выберите правильного провайдера с нужной связностью. Мне, к примеру, пинг в 90мс до Кореи не светит принципиально, потому что это физически невозможно.


                  traceroute как он есть. И что тут могут сделать шаловливые ручки людей?
                  traceroute to ppomppu.co.kr (110.45.151.153), 30 hops max, 60 byte packets
                   1  * * *
                   2  * * *
                   3  * * *
                   4  * * *
                   5  ae-35.a01.nycmny17.us.bb.gin.ntt.net (128.241.2.249)  2.161 ms  2.214 ms  2.217 ms
                   6  * * *
                   7  ae-3.r22.asbnva02.us.bb.gin.ntt.net (129.250.6.116)  7.875 ms  8.931 ms  7.908 ms
                   8  ae-5.r23.lsanca07.us.bb.gin.ntt.net (129.250.3.189)  79.181 ms  79.198 ms  79.103 ms
                   9  ae-5.r01.lsanca20.us.bb.gin.ntt.net (129.250.6.49)  72.243 ms  76.325 ms  73.715 ms
                  10  ae-1.a01.lsanca20.us.bb.gin.ntt.net (129.250.2.214)  72.316 ms  76.786 ms  77.942 ms
                  11  ae-0.lgu.lsanca20.us.bb.gin.ntt.net (168.143.229.202)  69.884 ms  69.874 ms  68.233 ms
                  12  1.213.145.25 (1.213.145.25)  184.072 ms 1.213.149.161 (1.213.149.161)  71.271 ms  67.078 ms
                  13  1.208.105.17 (1.208.105.17)  236.061 ms 1.208.104.89 (1.208.104.89)  232.588 ms 1.208.105.17 (1.208.105.17)  232.250 ms
                  14  * * *
                  15  1.208.167.94 (1.208.167.94)  228.812 ms 1.208.172.38 (1.208.172.38)  255.913 ms 1.213.152.194 (1.213.152.194)  247.512 ms
                  16  1.213.149.13 (1.213.149.13)  239.558 ms 1.213.150.250 (1.213.150.250)  245.855 ms 1.208.175.126 (1.208.175.126)  239.431 ms
                  17  117.52.240.50 (117.52.240.50)  231.977 ms 117.52.240.38 (117.52.240.38)  241.309 ms  228.226 ms
                  18  61-111-1-118.kidc.net (61.111.1.118)  237.097 ms * 117.52.240.34 (117.52.240.34)  241.652 ms
                  19  110.45.151.153 (110.45.151.153)  243.424 ms  245.889 ms *
                  20  * 110.45.151.153 (110.45.151.153)  237.823 ms  247.705 ms

                  • alliumnsk
                    /#21356436 / +1

                    Мне, к примеру, пинг в 90мс до Кореи не светит принципиально, потому что это физически невозможно.

                    Понятия не имею, где вы живете. Для Москвы, где наибольшая плотность хабраюзеров, пинг 90 мс до Кореи физически возможен. В Новосибирске, где я живу, тем более.


                    Универсальный совет, хотите небольшой пинг до XYZ — езжайте жить поближе к XYZ

                    вы это серьезно? Зачем тогда этот энторет если можно взять лошадку и приехать к человеку лично?


                    выберите правильного провайдера с нужной связностью.

                    Мне теперь под каждый сайт подбирать провайдера? А перед провайдерами еще слой аки костыльный NAT ставить?


                    Вы привели пример traceroute из IPv4. Автор поста указывает, что в IPv6 адреса выдаются иерархически, поэтому таблицы маршрутизации получаются меньше и проще. В IPv4 же у одной страны масса несмежных диапазонов, адреса в цепочке traceroute похожи на хэши. Вот я и подумал — может в сети ipv6 быть пинги хоть немного ближе к физически возможным станут… разве это не одна из первоочередных задач сети? (а не обеспечивать сетевых инженеров зарплатой).

                    • Tolmy
                      /#21356570

                      Для Москвы, где наибольшая плотность хабраюзеров, пинг 90 мс до Кореи физически возможен. В Новосибирске, где я живу, тем более.

                      Вы основываетесь на предположении, что существует прямой оптоволоконный кабель Москва-Сеул. Или Новосибирск-Сеул. Что цена на аренду канала в нем конкурентноспособна с остальными вариантами. Да что там цена, вообще просто есть возможность аренды, он не перегружен. Что Ваш провайдер прямо заинтересован в быстрой доставке контента из Южной Кореи своим потребителям и готов понести на это некоторые финансовые затраты. В таком идеальном мире да, до Новосибирска возможен пинг в 90мс. До Москвы — сильно сомневаюсь, на одной ретрансляции только больше потеряется. Это если не считать 50-60мс чистой задержки в стекле. Будет ближе к 200мс. Сорри, законы физики не обмануть.


                      от я и подумал — может в сети ipv6 быть пинги хоть немного ближе к физически возможным станут… разве это не одна из первоочередных задач сети?

                      Нет, это вообще никоим боком к версии IP не имеет. Физический и канальный уровень определяет всё и он никак не зависит от (желаемой) сетевой маршрутизации. А именно он будет определять задержки в канале. Есть прямой канал из X в Y, возможно на сетевом уровне будет принято решение использовать его. Нет прямого, из X в Y пакеты пойдут через Z. Из моего опыта пинги в IPv4 и в IPv6 примерно одинаковы, плюс-минус. Чуть меньше в IPv6 только из-за того, что там пока чуть меньше загрузка канала.

                      • alliumnsk
                        /#21357296

                        Вы основываетесь на предположении, что существует прямой оптоволоконный кабель Москва-Сеул.

                        отнюдь нет. Расстояние до Сеула через Владивосток, Хабаровск ненамного длинее прямого.


                        "зоконы физики" не определяют задержки на ретрансляцию, они могут быть сколь угодно малыми. То что может быть у провайдера клиенты хотят больше смотреть 4к видео на ютубе, чем пинг до Кореи, это не физика, это экономика. Но, простите, как говорил ОП, я хочу иметь интернет а не удаленный доступ до гугла и фейсбука.


                        Я всего лишь прошу чтобы пинг до Кореи у меня был в ТРИ раза хуже физически возможного, а не равным физическому пределу. А сейчас у меня до некоторых сайтов там пинг 450.


                        Из моего опыта пинги в IPv4 и в IPv6 примерно одинаковы, плюс-минус

                        в чьем юскейсе примерно одинаковы? Между Роттердамом и Франкфуртом наверное и так маршрутизация неплохая что в 4 что в 6. А у кого-то что-то в юзкейс как раз и не входит из-за плохого соединения. Как соединения поменяются, юзкейс тоже может поменяться.

                        • Tolmy
                          /#21359620

                          отнюдь нет. Расстояние до Сеула через Владивосток, Хабаровск ненамного длинее прямого.

                          А кто Вам сказал, что существует канал Владивосток-Сеул или Хабаровск-Сеул, что он не загружен настолько, что в этом канале возникают потери и маршрутизация на автомате не начинает избегать этого канала?


                          в чьем юскейсе примерно одинаковы? Между Роттердамом и Франкфуртом наверное и так маршрутизация неплохая что в 4 что в 6. А у кого-то что-то в юзкейс как раз и не входит из-за плохого соединения.

                          Вы по прежнему основываетесь на предположении, что существует какие-то особые специальные физические каналы для Интернета. На практике цифра и голос делят одни и те же мощности и выделение нового канала передачи данных — это выделение очередного контейнера в SDH в магистральном канале. Да, может быть такое, что Ваш провайдер по IPv4 подписал один договор, и по IPv6 — другой, с другим поставщиком. Но вероятность этого исчезающе мала исключительно по экономическим причинам.


                          "зоконы физики" не определяют задержки на ретрансляцию, они могут быть сколь угодно малыми.

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

                • Tolmy
                  /#21355024

                  Автор статьи, кстати, предлагал пихать в адрес человеко-читаемые рюшечки, по сути дублирующие DNS

                  Уже всё давно придумали до нас
                  Это всё просто замечательно, адреса типа ru/msk/south_butovo/gorchakova_st/43/app123 вообще прекрасно человекочитаемы и вполне себе содержат географические данные. Но. Сущая малость. Надо теперь научить машины(маршрутизатор, он тоже машина, только сильно заточенная на один специфический вид деятельности) разбирать такие адреса миллионами в секунду и на их основе строить маршрут доставки. Это такая малость, но портит абсолютно всё.

                  • alliumnsk
                    /#21357196

                    Strawman

                    • Tolmy
                      /#21359720

                      Ну нет же. Вы, вместе с авторами NDN, пытаетесь в сущности, предназначенные исключительно для машинной обработки, вложить удобные человеку понятия, категории и смыслы. Безусловно, это можно сделать. Но это лишь усложнит машинную обработку и, внезапно, не принесет никакой выгоды человеку. Вы на практике не пользуетесь IP адресами, вы используете DNS имя, которое как раз и предназначено для удобного использования человеком. А маршрутизатору абсолютно всё равно, есть ли какой-то физический смысл в IP адресе, который он сейчас форвардит, ему достаточно одной записи в таблице маршрутизации, по которой он примет решение.

  18. MikFoxi
    /#21338984

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

    • Tolmy
      /#21339036

      Вообще-то никто не мешает использовать NAT для IPv6. Это же только транспорт, ему все равно, какие технологии поверх него используются.

      • MikFoxi
        /#21339050

        Готовых костылей запилить ipv6 nat вроде ж нету. Лучше иметь ipv4 локалку с локальными адресами.

        • Tolmy
          /#21339084

          Угу. И однажды не получить доступ к очень нужному в данный момент ресурсу, который IPv6 only. А такие уже вот прямо сейчас есть. Мне лично транспорт как таковой неинтересен, мне ехать, а что там под капотом, всё равно. Но ведь жизнь заставила сесть и всё настроить. Так вот, заглянув под капот, я понял, что там в общем всё в порядке, ездить можно. Но тут уже сотни сообщений настрочили, что я ошибаюсь, и мне IPv6 не нужен и даже вреден. Ну ок.

          • MikFoxi
            /#21339102 / +1

            Не бывает важных IPv6 only ресурсов и в ближайшие лет 20 не будет.

            • Tolmy
              /#21339104

              Ну вот у меня есть ;) Ресурсы, которые позволяют мне зарабатывать деньги — это достаточно важные ресурсы?

              • powerman
                /#21339364

                Список в студию, плз.

                • Tolmy
                  /#21339452

                  Я на них деньги зарабатываю, NDA.
                  Я об этом выше уже писал. Внутренняя сеть компании — IPv6 only. Active Directory, IIS, ERP, MS SQL и Oracle, всё на доменных именах и IPv6. Nginx вот правда, с веб-сайтом компании, наружу торчит в IPv4. Вернее, в dual stack. В запросе к сетевикам, когда я хочу новую виртуалку задеплоить, вопрос про IPv6 вообще не стоит, а вот вопрос "нужно ли выделение IP4 адреса" имеется. И потом в списке из семи пунктов, почему нужно выделять IPv4 адрес, нужно выделить один или несколько пунктов. Первый пункт — "будет использоваться ПО, которое не поддерживает IPv6 и нет возможности это ПО не использовать". Последний — "требуется для разработки и тестирования". Тогда под виртуалку выделят отдельную железку, которая включена в отдельный влан из отдельного коммутатора. После чего мне нужно будет, по имеющемуся опыту, от двух недель до месяца ждать, пока вся эта корпоративная бюрократия предоставит мне к такой виртуалке удаленный доступ. А вот если она обычная, IPv6 only, то через пару дней максимум. Поэтому у меня никогда не возникает соблазна поставить галку "нужен IP4", ну его нафиг. Да и не было необходимости никогда.

                  • powerman
                    /#21339652

                    Если я правильно понял MikFoxi (а если нет — он поправит), то речь шла вовсе не о внутренних ресурсах, а о популярных сайтах во внешнем инете.

                    • Tolmy
                      /#21339782

                      А. В этом смысле да, не думаю, что это будет скоро, популярные сайты только на IPv6. Наиболее вероятный сценарий — гугл начнет снижать рейтинги показов сайтов в поиске за наличие IN A записи в DNS. И вот как только он об этом только объявит, начнется массовый отказ от IPv4 ;) А он вполне такое может запилить. Но, как я уже говорил, мне в общем всё равно, что, кто и как использует. Мне не шашечки, мне ехать. Будет IPv6 Ok, хорошо. Запилят какой-нибудь IPv2020 — ну да ладно, будем его использовать, когда надо. В начале 90-х я в одном министерстве убеждал типа именитых профессоров и к.т.н., великих технических специалистов, что X.25 это безусловно круто, но будущее за TCP/IP. Было весело видеть их унылые лица, да. А ещё раньше, в начале 80-х, я получил трояк за курс "теория СВЧ устройств", потому что сказал, что однажды технология производства полупроводников позволит работать в гигагерцовом диапазоне без всяких магнетронов и всей этой посеребренной канализации. Жаль, что препод не дожил до IEEE 802.11ac в коробочке, которая продается в каждом супермаркете.

                    • MikFoxi
                      /#21340268

                      Да тут уже кто о чем, каждый о своем ))
                      Мое мнение:
                      Как клиенту инет провайдера, ipv6 мне не нужен и даже вреден (если внедрять по полной и пров будет раздавать подсеть чтоб каждому утюгу по выделенному ипу), потому что это нарушит безопасность моей локалки, да и куча устройств у меня которые не поддерживают ipv6.
                      Как админ сайтов — надобности в ipv6 мне нету, т.к. у всех посетителей всегда есть ipv4, сайты мои в РКН не забанены, чтоб иметь запасные ипы. Зато вред от ipv6 сайтам есть, изза того что их безлимит (благодаря утюгам, имеющим белый ipv6 и выход в интернет и которые уже взломаны), хоть поштучно, хоть подсетями учитывай, с них немерянно валится чернухи — ддосеры, брутфорсеры, поиск уязвимостей, создающих нагрузку и опасность серверу, тенденция эта постоянно растет и будет расти. Потому я даже сайтам которые за cloudflare отключаю ipv6, чтоб видеть меньше мусора в логах.
                      А популярные сайты, инста, фб, ютуб и т.п. которым как бы по статусу для солидности надо иметь ipv6 — их от этого парсить проще, дешево взять ipv6 проксей и качай сколько хочешь, с ipv4 проксей их парсить можно разориться.

          • MikFoxi
            /#21339106

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

            • Tolmy
              /#21339140

              ну так dual stack вроде пока никто не отменял. Я на хабре тоже не с IPv6 адреса пишу, у него его даже нет.

          • zurapa
            /#21357228

            Вы уже тратите администрирование сетей больше. Хотите чтобы все этой х… ней занимались? Оставьте только ipv6, коли вы такой евангелист и напишите мне через полгодика, сколько ресурсов из вас нужных вам не ответило.
            Я правильно полагаю, что пока Хабр не включится в ipv6, вы мне не ответите?

    • Ankoroid
      /#21339422

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

      Ну так не выпускайте — настройка ipv6 firewall часто это просто 1 крыжик в веб-интерфейсе.
      Он даже может быть уже включен по умолчанию.

    • ivlad
      /#21340312

      изза которого я для себя буду максимально оттягивать всеобщий приход ipv6

      у вас просто в какой-то момент IPv4 связанность исчезнет, да и всё. Мне попадались уже публичные WiFi сети с IPv6 only и NAT64. Не замечал, пока не захотел что-то пингануть.


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

      Вы не понимаете, как устроена безопасность и чем трансляция адресов отличается от фильтрации трафика. Ничего не мешает SOHO устройствам фильтровать по умолчанию соединения изне внутрь. Более того, они так и делают.


      Да и вообще, вот публичная оферта: адрес моего домашнего принтера 2401:7400:C802:16E3:8625:19FF:FE73:ED3D. Первый, напечатавший на нём свой PayPal адрес получит туда перевод в 100 USD. Роутер RT-AC1200G+ с настройками IPv6 по умолчаниюю. Вперёд.

      • dragoangel
        /#21340630

        +++ люди от непонимания и не знания путают Nat с Firewall.
        В добавку к всем плюсам IPv6 добавлю что DNSSEC который имеет в мире распространение в 2% всех клиенских зон (3 уровня и выше) на мой взгляд тормозится именно из-за IPv4, ибо SlitDNS с DNSSEC эта та еще боль, которая попросту не нужна в случае использования прозрачной маршрутизации IPv6. Что бы его завести приходится вырубать DNSSEC валидацию для своих субдоменов, либо делать свои приватные DNS публичными и на них настраивать IP Scope

  19. JayK
    /#21340922

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

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

    А так то да, половина маршрутизации это есть костыли направленные на устранение несоответствия числа хостов числу айпи адресов…

  20. DJArty
    /#21341744

    Предлагаю автору от теоретического описания плюсов ipv6 перейти к практической демонстрации как всё в действительности сейчас. Как все это выглядит для среднестатистического пользователя.
    На примере среднего роутера типа упоминавшегося в ветке asus ac1200g+ показать что где включалось, настраивалось. Какой провайдер какой ipv6 выдал. Какие разные устройства подключаются к этому роутеру и как безопасно они себя чувствуют "вывалившись" в сеть. Какой фаервол на роутере, какие фаерволы на компе с виндой с линуксом, вайфай часах, каком нибудь увлажнителе с файфаем, принтере, телефоне на андроиде или иосе, каком нибудь шлюзе умного дома и лампочках с вайфаем, медиаплеере.
    Как подключаются в эту схему старые устройства с ipv4 только.
    А главное показать безопасность всего этого. Попробовать провести "проникновение". Проверить не светит ли в сеть какойнибудь домашний медиасервер с домашним видео или nfs шара или самба. Нужны ли и есть ли фаеволы на конечных пользовательских устройствах или достаточен файервол на обычном роутере и достаточен ли.
    Вот тогда на реальном примере станет яснее хорош ли ipv6 и не пора ли его использовать.

    • JayK
      /#21341936

      -Как все это выглядит для среднестатистического пользователя.
      Никак оно не должно выглядеть, плагэндплей.
      -Какой провайдер какой ipv6 выдал
      В РФ никакой не выдаст, version6.ru/isp, вы видели в списке роскомпозора в6 адреса? А какой выдаст там все это ограничится внутренней сетью без маршрутизации в интернет, на радость мамкиным хацкерам из этой сети.
      -Нужны ли и есть ли фаеволы на конечных пользовательских устройствах
      Файрвол? Какой файрвол? Астрологи объявили неделю снижения цен на дедики!

      • ne_kotin
        /#21342406 / +1

        В РФ никакой не выдаст

        МТС и Скайнэт выдают. Глобально маршрутизируемые.

        • stetzen
          /#21342442

          Ростелеком в Москве тоже выдаёт, во всяком случае некоторым пользователям.

        • JayK
          /#21342834

          Хм, а как это выглядит? Из коробки? А на заблокированные сайты можно зайти если у них есть в6 адрес? 2a02:4680:22::214 2a03:42e0:0:0:0:0:0:214 например

          • ne_kotin
            /#21343314

            для МТС в APN надо включить IPv4+IPv6.
            Скайнет пока в тестовом режиме — заходишь в личный кабинет, взводишь галочку, забираешь префикс и настраиваешь его в роутере.

            • JayK
              /#21343366

              Так открывается рутрекер или нет? Нету к сожалению мтс проверить.

              • MoreDerevo
                /#21345190

                проверил не открывается
                на ипв6 очень много сайтов не открывается, в яндексе есть проверка — мол работает сайт через ипв6 или нет

              • StJimmy
                /#21348468

                Какая разница, какая используется версия сетевого протокола, если по крайней мере rutracker заблокирован по домену?

        • edo1h
          /#21346636

          МТС и Скайнэт выдают

          мтс проводной не выдаёт. у нас, во всяком случае

          • ne_kotin
            /#21346784

            сорри, речь про мобильный МТС

            • alliumnsk
              /#21356452 / +1

              хм, интересно… два телефона с ipv6 адресами могут связаться напрямую, минуя провайдера?

              • ne_kotin
                /#21356566

                Ессна. Адреса же глобально маршрутизируемые.

              • Tolmy
                /#21356590

                Что понимается под словами "напрямую, минуя провайдера"? Минуя маршрутизацию через оборудование мобильного оператора? Нет, и тут версия протокола или адресация не при чем. Канальный уровень, передача сигналов в сотовой сети так устроена, что это невозможно.

                • alliumnsk
                  /#21357302

                  Понимается, что по вашему совету, юзеры взяли лошадок и едут навстречу друг другу. Пока они далеко, сигнал идет через провайдера. Как они оказались в прямой видимости, маршрутизация прозрачно меняется.
                  Вопрос в том, насколько это достижимо на практике

                  • ton1
                    /#21357712

                    Такое возможно в случае альтернативного mesh протокола — yggdrasil например. Провайдерам делать такое очень западло — они потеряют возможности контроля.

                  • Tolmy
                    /#21359442

                    Это недостижимо по политическим причинам. Государство просто не допустит существование таких протоколов передачи данных. Ни у нас, ни в самых распрекрасных оплотах демократии. Но особенно у нас. Поэтому только так, любой чих — через мобильного оператора. И — в папочку.

      • Sugrob
        /#21344898

        > В РФ никакой не выдаст, version6.ru/isp, вы видели в списке роскомпозора в6 адреса? А какой выдаст там все это ограничится внутренней сетью без маршрутизации в интернет, на радость мамкиным хацкерам из этой сети.
        1) Выдают глобально маршрутизируемые
        2) У меня свой роутер, настраивал сам
        3) Рутрекер доступен по https

      • gxcreator
        /#21348502

        Дом.ру в НН на PPPoE выдает глобальные

    • ivlad
      /#21344422

      Как все это выглядит для среднестатистического пользователя.

      1. пришёл монтажник, принёс маршрутизатор, телефон и ONT, подключил, сказал пароль от WiFi и админки маршрутизатора.
      2. Я зашел в админку маршрутизатора и в разделе IPv6 выбрал native или что-то такое. Остальные настройки остались по умолчанию, насколько я помню. Это три года назад было.
      3. Появилась IPv6 связанность.

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

      На линке я вижу 8 устройств. Кажется, это 2 ноутбука, 2 телефона с iOS, NAS, Apple TV, принтер, маршрутизатор. Sonos и Kindle Paperwite не умеют IPv6 и в том же L2 сегменте получают адреса посредством DHCP, ходят через NAT. Kindle Fire, на андроиде, как пишут, умеет IPv6, но мне куда больше нравится Paperwhite.


      Какой фаервол на роутере

      Встроеный.


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

      Встроенные или никаких. В принтере точно никакого нет. Я уже предлагал: адрес моего домашнего принтера 2401:7400:C802:16E3:8625:19FF:FE73:ED3D. Первый, напечатавший на нём свой PayPal адрес получит туда перевод в 100 USD.

    • zurapa
      /#21357250

      Я на дня выступление слушал, там человек про iOS странности в ipv6 рассказывал. Если резюмировать, то в ipv6 iOS голой жопой наружу, и весьма несложно ломается и ничего с этим не поделаешь, там ещё описывался факт подмены маршрутизатора для iOS. Ей можно широковещательным пульнуть, что её ip хотят и она новый попросит у маршрутизатора. Так что с ipv6 мальчики просто не сталкивались ещё с проблематикой, когда поведение смартфона в сети никак не откорректировать, остаётся с этим жить. Только с ipv6 придётся с этим жить в публичной сети. Кстати, кто знает, как в iOS настраивается фаервол?

      • ivlad
        /#21359612

        Можно ссылку на выступление?

  21. zurapa
    /#21351300 / -2

    Кто-нибудь! Расскажите этому мальчику о недостатках и нерешённых проблемах, которые ставят под вопрос целесообразность внедрения этой технологии. Ситуации с wi-fi, который везде и всюду уже достаточно, чтобы не продолжать.

    • ne_kotin
      /#21351374 / +1

      Что не так с v6 в Wi-Fi, расскажите пожалуйста?
      В домашней сети с /64 на роутере — просто работает (SLAAC, RADVD).

    • develop7
      /#21351408 / +1

      Раз вы, без сомнения, осведомлены о, и уж наверняка во всей полноте, может, стоило бы взять, да снизойти до убогих, осияв их светом подлинного знания, нет? Такую миссию кому попало доверять, знаете ли, неразумно — могут не донести.

      • zurapa
        /#21357260 / -1

        А вы бы не тратили время на чтение комментариев, псевдоучёных, которые в основном зарабатывают рейтинг перед будущим работодателем, а почитали бы больше статей по проблематике использования ipv6. Или вас родители не научили кучку сначала нюхать, потом пробовать на зубок?
        Тут пару тролей засело, и уже массу времени потратили люди на аргументацию, однако бесполезно. Предпочитаю намекнуть, а там уже каждый сам для себя решит: почитать или минуснуть. Пока, что получается собрать статистику по минусам. Адекватных людей сложней вычислить.

        • ne_kotin
          /#21357532 / +1

          Это так не работает. Изволите постулировать — аргументируйте.
          IPv6 хорош как раз тем, что убирает массу болячек v4 — дефицит адресного пространства, как следствие — необходимость в NAT, зависимость конфигурирования сети от DHCP. При наличии /64 на роутере и разрешенном SLAAC+RAD все просто работает автомагически — вставь провод и готово.
          Выдача /64 из /56 или /48 тоже вполне регламентированная процедура.

          Т.е. проблем с внедрением и использованием v6 нету. Есть проблема с ленивыми задницами в операторском бизнесе.

        • develop7
          /#21357874

          а почитали бы больше статей по проблематике использования ipv6

          следует понимать, что ссылок ждать от вас не стоит?

  22. alliumnsk
    /#21352956

    Пост очень длинный, поэтому я сделал короткий реферат, оставив только самое важное.


    никогда
    Интернет
    эффективно и удобно
    очень эффективно, продуманно и удобно!
    просто и удобно!
    очень удобно!
    очень эффективно, продуманно и удобно!
    продуманно!
    Killer-feature
    невероятно удобно!
    легко
    Killer-feature
    эффективно и просто!
    очень эффективным!
    эффективно
    очень удобно и продуманно!
    просто и эффективно!
    продуманно и эффективно!
    продуманный
    эффективно

    • zurapa
      /#21357268 / -2

      Красавчик! Прям тезисы! Ты наверняка отличник был в университете! Я бы два плюса поставил, но могу только один. Извини.