Pull to refresh

Comments 281

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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


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


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

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


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


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


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


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


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


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


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


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


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


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


Все.


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

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


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


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


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

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


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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбирайте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

не знаю как у вас но у меня в миллионном городе нет ни одного провайдера с ipv6 и так по моему в о всем мире кроме штатов. И хотя дома подключено два провайдера по оптике — но у обоих ipv6даже не планируется. То зачем в домашних роутерах IPv6 производителям замарачиваться?

Ошибаетесь. Мобильный МТС опционально поддерживает IPv6. К тому же кроме штатов в этом списке Германия, Франция, Англия, Индия. Всё это не маленькие рынки.
Замените здесь «включить v6 через Hurricane» на «построить VPN», и «включить NAT с пробросом портов» на «настроить фильтрацию трафика при условии, что все машины в локалке получили белый IP» и вы получите то, с чем реально столкнулись.

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

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

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

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


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

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

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

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

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

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

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


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

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

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


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

UFO landed and left these words here

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


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

UFO landed and left these words here

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

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

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

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

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

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

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

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

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


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

Ну и в итоге,


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

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

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

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

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

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

Ну почему же "существовала"?
Я до сих пор страдаю, когда не могу открыть файл с шары NFS, где в кириллическом имени диакритика (ё или й).
Или когда сохраняю — и вместо перезаписи предыдущего файла рядом сохраняется новый. С тем же именем.

Лень поднимать NFS и проверять, но вроде как в NFSv4 использование UTF уже обязательно?

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

Что-то я не догоняю. Какая связь между тем, что два кодпоинта рендерятся визуально одинаково с «не могу открыть файл»? Если бы проблема была в этом, то ей бы страдали все ФС с поддержкой юникода. Или вы имя для открытия файла набираете вручную каждый раз?

Связь в том, что имена хранятся вполне валидным utf-8, и файловой системе всё равно, какие именно там байтики.
А вот операционке уже не всё равно.
Например, на ntfs я вполне могу сохранить файл со скобочками, слэшами и прочими знаками. Из убунты или мака. Но винда потом такой файл не откроет. Но это явный пример, и не относится к юникоду вообще никак.
А во то, что та же убунта сохраняет имя с буквой ё или й внутри как один кодпоинт, а мак этот файл потом напрочь отказывается открывать — это уже как раз заморочки юникода.

Логичнее предположить, что это заморочки мака. Или где-то есть спека с разрешёнными для мака кодпоинтами в именах? Если там есть диакритика, то это баг оси, а не юникода.

Я всё же склонен думать, что это именно исторический баг (или фича) юникода.
То, что можно одно и то же выразить кардинально разными способами, и это приводит, порой, к проблемам — как раз следствие такой архитектуры.
То, что apple решили все буквы с диакритикой кодировать сочетанием буква + диакритика — вполне разумно и последовательно.
То, что остальные "исторические широко известные" буквы с диакритикой кодируют одним кодпоинтом, соответствующим букве — тоже вполне логично и объяснимо.
Оба подхода вполне юникодные. Но разные.
Потенциальные проблемы начинаются там, где эти два подхода встречаются. И приходится с этим как-то жить теперь.
Научить мак открывать файлы с именами с диакритическими буквами наверное можно, но это только костыль. Сразу вылезут — а как пересохранять? А как, если в файле оба варианта? А как, если сохранить с шары на локальный диск? Даже банально — как эти имена различать? strcmp уже не вариант, придётся лезть в icu, а это небыстро. И если подумать — ну его, этот костыль. Проще просто не давать открывать и не думать обо всём этом.


(кстати, в коде страницы — текст гоняется через icu, или хранится, как есть? Пишу с мака, должны быть спаренные кодпоинты)

А чего macOS учить открывать? Он их нормально не только открывает, но и создаёт. Например, легко проверить:
$ mkdir /tmp/t/shell-ё
$ ls /tmp/t | od -c
0000000    f   i   n   d   e   r   -   е  **    ̈  **  \n   s   h   e   l
0000020    l   -   ё  **  \n                                            
0000025

, что Finder создаёт NFD нормализованные имена, а bash точно такие, какие заданы аргументом (и, в данном случае, Терминал вводит букву «ё» одним символом Unicode).

В общем, APFS относится к нормализации Unicode так же, как к регистру символов: храним как создавали, а при открытии, поиске и сравнении нормализуем, т.е. все варианты «ё», «ё», «Ё», «Ё» (упс, в комментарии нормализация NFC) открывают один и тот же файл.

А например, NTFS под Windows, несмотря на аналогичную нечувствительность к регистру, работает иначе («ё», «Ё» — это один файл, а «ё», «Ё» — это другой файл, и перепутать просто невозможно ж):
image

Ясное дело, в ZFS и прочих ФС у Solaris, Linux, FreeBSD: «ё», «ё», «Ё», «Ё» — четыре разных файла. Что, как бы, тоже понять можно, в отличии от NTFS/Windows.
> Я всё же склонен думать, что это именно исторический баг (или фича) юникода.
То, что можно одно и то же выразить кардинально разными способами, и это приводит, порой, к проблемам — как раз следствие такой архитектуры.

Недавно обсуждал эту тему на RSDN и пришёл к выводу, что такие вещи вообще надо уметь настраивать на уровне FS или конкретного каталога — как именно в нём будут обрабатываться имена. Или вообще без конверсии (Unix style), тогда и регистр будет различать имена; или назначать какой-то collation, но тогда вместе с выбором конкретной формы нормализации.
Плохо то, что помещать весь этот ужас в ядро — опасно, а выносить на userland — значит, каждому может подключаться библиотека нормализации… ну стиль Windows с его принудительным прохождением через dll — такое потянет, а вот остальным придётся костылить. (VDSO?)
Нет, это выглядит, как баг конкретного софта, который у себя внутри зачем-то нормализует названия файлов, а потом пытается открыть файл по нормализованному имени. Или что-то в этом роде.
Помните, как в 90-е и начале 2000-х при том, что поддержка Unicode в мэйнстримных ОС существовала уже многие годы, регулярно возникали проблемы с кириллицей в путях и прочих строковых данных?

Они и сейчас есть почти повсюду (JetBrains, Ansible, Gitlab, WSL, Visual Studio — это то, где за последний год сталкивался, где-то ошибки в продуктах, где-то в платформах/библиотеках). У меня на одном из компов дома на винде домашний каталог на кириллице и с пробелом, я все эти грабли собираю. Принципиально путь не меняю: если всё совсем не обходится, то либо на другом ПК, либо в виртуалке. Если хорошо воспроизводится — пишу тикет.

Сделать новый формат пакета, а в остальном все оставить как есть
Ну так ведь именно это и было сделано — формат заголовка IPv6 отличается от формата заголовка IPv4. Остальное в общем работает так же, разве что исправили несколько врождённых проблем четвёрки.

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

Инерция легаси ровно ничего не говорит об архитектурной грамотности решения. Вон, x86 ISA по современным представлениям — ужасен, но его лидерство неоспоримо при наличии гораздо более грамотно спроектированных архитектур.

Нет никакой инерции легаси, есть неумение проектировать системы с расчетом на миграцию. Посмотрите, как сотовая связь мигрировала уже сколько раз, как вайфай сети, USB стандарты, да куча всего — и у всех было легаси, и все справились. А тут никак. Может, в консерватории что-то поправить надо?

Всё там в порядке с расчётом на миграцию.
Например, если вы не в курсе, :FFFF:216.58.208.206 является валидным IPv6 адресом с точки зрения ОС работающей в дуал стэке.

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

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

За 20 лет внедрения IPv6 обновились, думаю, все сетевые устройства и по несколько раз, просто трафик вырос на порядки, старые бы не справились. Технологии двадцать лет! Какое легаси, она уже сама легаси!


Ещё раз, две проблемы:


  • отсутствие внятной, бесшовной, всегда работающей обратной совместимости. В двойном стеке новый не заменяет старый, он параллелен, и если его специально не использовать — его как будто нет, и стало быть, если он даже и включен — его косяки никто не видит — и, разумеется, не исправляет. Если бы DHCP модифицировали так, чтобы он мог сам выбирать лучший стек из возможных, например, постепенно все бы сами перешли, потому что это бесшовно, а проблемы бы исправлялись по мере их возникновения. Но тогда никаких новых архитектур, да. Но именно так пошли wifi и все прочие успешные примеры.
  • и да, платить специально за IPv6 никто не хочет, потому что преимуществ для пользователя нет.
Технологии двадцать лет! Какое легаси, она уже сама легаси!
Вы, по-моему, путаете дату начала разработки и фазу внедрения. Всемирный день запуска IPv6, когда его одновременно включили все магистральные операторы на сутки, посмотреть, что будет — произошёл совсем недавно, 6 июня 2012 года. До этого, по-моему, даже межсетевая связность не гарантировалась.

Обратная совместимость в IPv6 есть. Внятная, бесшовная и т.п. Кривые руки админов и страстное желание вендоров SOHO сегмента ориентироваться на среднего листателя вконтачика — не проблема архитектуры IPv6.

Развитие WIFI пошло экспансивным путём, типа оверклокинга. И отличаются разные его поколения, с бытовой точки зрения, ТОЛЬКО скоростью радиоинтерфейса. Качественно новых решений такой подход дать не может, а в IP именно они и требовались.

Уже устал спорить...


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


Странно было бы, если бы админы решали бы не задачи своего работодателя, а чьи-то ещё.


Разумеется, у WiFi с бытовой точки зрения разница лишь в скорости. С этой же точки зрения между IPv6 и IPv4 разницы нет вообще.

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

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

Заметил такую штуку. Люди приобретают дорогие ноутбуки, тщательно выбирают сотовый телефон по характеристикам. А домашний маршрутизатор берут самый дешёвый. А зачем заморачиваться, WiFi он и в африке WiFi. Да ещё и древний ADSL требуют настроить для провайдера с Ethernet доступом. IPv6? А без него котики будут грузиться? Тогда и не нужен.

Обратная совместимость и legacy бывает не только по железкам, которые заменили для того, чтобы справится с трафиком. Но и у того, что вокруг железок. Если биллингу оператора каким-нибудь образом сносит крышу от IPv6 трафика, то оператор его включать не будет, даже если все железки уже его умеют.

Домашний роутер у меня поменялся за 20 лет раз 5. Провайдер раза 3 или 4 (не считая nG) и вроде даже сейчас в обоих домашних роутерах ipv6 есть (в одном из них только что проверил — есть, отключен). И толку, если у провайдеров нет?

> Сделать новый формат пакета, а в остальном все оставить как есть.

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

> накатить апдейт, который просто включает ещё один новый режим, как TLSv1.2 -> TLSv1.3

У этих двух TLS вообще-то больше различного, чем общего. Так что это всё равно аналог двух стеков, просто контекстом можно задавать «а вот с этим адресом мы общаемся вот так-то». И там нет проблемы типа «нам вообще v4 на всех не хватает».

> но все как-то обходились без необходимости разломать все кругом. Это если об этом всем думать, конечно.

Увы, сравнивать случаи тут сильно сложно именно из-за расширения адресации.

Вот я примерно про то же говорю — можно было сделать как расширение, а не как все новое, и все бы перешли.

Использовал ipv6 от Hurricane Electric, но некоторые сайты постоянно просили ввести капчу (привет яндексу). Пришлось отказаться от ipv6.
Этого брокера абузят спаммеры, а политика модерации там никакая. Поищите локального, у них таких проблем обычно нет.
Вот заняться больше нечем, кроме как искать локального! Поймите, если проблема решается двумя способами: один из них простой и быстрый, а второй — длинный и сложный, то в 99 случаях из ста (образно говоря) она будет решена простым и быстрым способом. В данном конкретном случае — отказом от ipv6.
использование брокера это и есть костыль. Ничего удивительного, что с ним всё плохо работает.
ip6 не человекочитаемый адрес, в отличие от простого, удобного ip4. Вот реально было б простое увеличение групп ip4. Давно бы уж все на ip6 сидели.
Глупости. Это вообще наименьшая из проблем. В IPv6 на самом деле много сделано, чтобы необходимости запоминать адреса у нормальных пользователей вообще не возникало, и частично от этого и возникают проблемы с переходом на него. Просто к IPv4 все уже привыкли, все знают что такое DHCP, как работает и зачем применяется, а как только выясняется, что в IPv6 можно обойтись без вот этого всего, начинается ступор и непонимание.

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

Нормальные пользователи — это те, которые чтобы обеспечить удаленный доступ к файловому архиву домашнему, покупают домен себе и DNS настраивают?

Если у них есть необходимость удалённого доступа к домашнему архиву, они уже не нормальные, а продвинутые :)
А если денег жалко, есть бесплатные dynamic DNS.

Что там продвинутого USB-накопитель в роутер воткнуть и галочку в админке поставить?

Эээ… ну я себе не так домашний NAS представляю, если честно :)
У меня это отдельный сервер с RAID0, самбой и SFTP.
А что в этом сценарии меняется с переходом на IPv6? Придется две галочки ставить, вторую на DynDNS?

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

А что домохозяйка делает, когда у неё IPv4 дома?
Во-первых, как уже ответили, DynDNS решает, во-вторых, проблема-то сейчас не в том, чтобы получить доступ к файловому архиву, ведь правда? Проблема в том, что я не могу у себя дома даже настроить его по IPv6, потому что провайдер не даёт IPv6.
Т.е. проблема с запоминанием адресов, возможно, есть, да только вот это далеко не самая главная проблема, и уж точно не нерешаемая. К примеру, у меня провайдер даёт динамический белый IPv4 — я даже не знаю, какой он у меня сегодня (надо в настройки роутера или на 2ip идти), так что теперь, может IPv4 надо на свалку отнести?

Мне тоже даёт динамический белый IPv4, как лет 5 назад дал, так и не забирает. Да, если роутер оставляю выключенным на неделю, может и заберёт, но пока нет.


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

В первом сообщении было написано, что главная проблема IPv6 — незапоминаемые адреса. Но на самом деле это вообще не проблема: если бы провайдеры массово поддерживали IPv6, переход уже состоялся бы, невзирая на то, хотите лично вы IPv6, или нет. Если вы думаете, что провайдеры не поддерживают IPv6 только потому, что их админы не хотят запоминать новые адреса, вы сильно ошибаетесь. Они действительно не хотят их запоминать, просто им это вообще не нужно, дело вообще совсем не в этом. И вообще никому это не нужно, кроме дебага каких-то своих локальных проблем с DNS.
Т.е. основная проблема — это именно нежелание провайдеров разбираться с настройкой IPv6 у себя, и с поддержкой IPv6 у клиентов. И в общем можно их понять, потому что всегда найдется процент клиентов, у которых что-то не заработает и им надо «срочно всё починить», сами они ничего не понимают, но их знакомый что-то понавертел в настройках, а пароль от роутера они не знают и вообще раньше всё работало, верните как было.
Только вот чем больше клиентов, тем больше этот процент, и откладывание на потом лишь отсрочит это, но не исправит. В остальном же сделать так, чтобы IPv6 работал так же plug'n'play, как сейчас IPv4, совершенно реально, и никакие адреса запоминать для этого не требуется.
Статья, честно говоря, скорее крики паники и непонимания где лишь малые капли «правильной» правды.
1) Брокеры это скорее зло, спасибо спамерам. Но даже без спамеров это можно сказать «демо» чтобы просто посмотреть. К слову сейчас все браузеры(может не только?) имеют особенность что v6 в приоритете но если он хоть чуть чуть задумался то идет fall-back на v4, как понятно с брокерами такая ситуация будет чаще всего.
2) Фаирвол, лично на мой взгляд это лучше nat'а. Блочим все «новые» входящие соединения а установленные пропускаем. Это в разы удобнее nat'a, вполне годится для «коробочного» решения для домохозяйки.
3) Преимуществ v6 дает очень много за счет белых адресов. При чем эти плюсы идут как пользователю так и сервисам. Скажем так что пользователя не будут раздражать капчи, всякие проверки «а это точно вы, а то чет подозрительное место откуда вы зашли». Для сервисов опять же польза, по части голосового трафика(а сейчас это ой как актуально изза поголовья мессенжеров) может люто экономить на всяческих stun\turn серверах да и самой сложности разработки т.к. можно принять за факт что кошмара в виде nat больше нет и нужно учитывать только фаирвол клиента.

С чем согласен:
1) Запись ipv6 адресов это тихий ужас, вот как ни старался ну не воспринимает мозг такое.
2) Даже если провайдер умеет ipv6 то это крайне не очевидно, крайне сложно и мало того почти не документировано. Т.е. фактически я встречался что «таки да, v6 у нас есть, можете вот так включить но дальше с настройками мучайтесь сами». И я не про настройку именно софта а банальные вещи типа узнать адрес шлюза, префикс и т.д.

С точки зрения прелестей которые может дать v6, сугубо с моей колокольни, скорее теоретические но вполне реальные:
1) Авторизация по ip. Ну условно у нас есть некая «дефолт» соцсеть(да что угодно). Авторизовались в нем со своих заведомо известных ip адресов(мобильный\домашний интернет) и включили в нем запрет на новые авторизации. Никто не «взломает», ни по брутит.
2) Прелести rtp\udp трафика в обе стороны, есть только фаирвол и разработчику надо знать только о нем. Тут тебе и сильное упрощение ныне кошмарно усложненного VoIP, и упрощение для любых realtime сообщений. Да даже для обычного трафика есть польза, хоть напрямую мессенджеры сообщения могут слать или пользователи между собой. В куче это огромные преимущества, разгрузка сервисов, удешевление их содержания и разработки.

По своему опыту сейчас:
— провайдер дом.ру (чтобы не было рекламой провайдер шлак, УГ и т.д.)
— информации у провайдера о тонкостях, ноль с хвостиком
— дают бесплатно
— дают динамический префикс /64. Вытекающее из этого уже понятно.
— статические префиксы, когда появятся, будут за отдельную плату. Ироды.
— выдача идет через DHCPv6-PD поверх PPPoE. Жесть. Т.е. упала ppp сессия упал и v6
— dns не выдают, т.е. АААА запросы получаются через dns v4. Опять же странное решение.
— шлюз через «link-local» провайдера. Тоже странно для меня.
— pihole говорит что у меня 35.4% запросов на ресурсы с v6. Не проверял но логично что v6 имеет приоритет для таких ресурсов.
— пару раз ловил улыбку, вдруг отваливаются некоторые сайты, другие работают. У провайдера повисла сессия pppoe но живой каким то чудом v6, соответсвенно v6 сайты работали =D

PS длинное рассуждение получилось и всеравно не все написал что хотел.
2) Фаирвол, лично на мой взгляд это лучше nat'а.

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

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

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

За смену провайдера Интернет (скажем, МТС на Теле2), а тем более за резервное подключение, можно и не вспоминать.

Большие организации, конечно, могут разграничить с поставщиком(-и) Интернет области ответственности, скажем, получив автономную систему. Но зачем это им, если мелкие организации, а тем более домашние пользователи с IPv6 не дружат?
Использовал Дом.ру в Казани. Так они иногда (раз в месяц или, может, в день, не помню) вместо запрошенной страницы отдавали страницу от Дом.ру, сообщающую о чём-то, о каких-то акциях вроде. То есть набираешь какой-нибудь url, нажимаешь enter, и получаешь рекламу Дом.ру. Не помню, работало ли это с https (если работало с https, то не понятно, как они этого добились). Вроде даже wget из консоли в линуксе мог их страницу скачать вместо запрошенного сайта (а значит, любые скрипты для автоматической закачки чего либо ломались). Так вот, они это пофиксили?
Проблема IPv6 только одна — нет дефицита — он не приносит денег. IPv4 можно продавать, а IPv6 — нет. Поэтому те кто имеет деньги с IPv4 всячески и успешно уже многие годы саботирует IPv6
Очередная теория заговора? Не надоело сочинять ещё?
IPv6 никто не саботирует, просто по IPv4 сейчас работает и умеет работать практически всё, от «умных» лампочек до чего угодно. Если я буду открывать интернет магазин, который работает по v6-only, туда никто не придёт, потому что распространение IPv6 среди пользователей слишком низкое, вот и всё. С обратной стороны та же ситуация: провайдеры не занимаются настройкой IPv6, потому что не хотят себе новых проблем на ровном месте.
Единственный стимул будет тогда, когда появится нужная всем штука, которая не работает по IPv4. Пока же ситуация ровно обратная: github, к примеру, не доступен по IPv6.
Да бред, все знают что IPv6 проще. Тот кто умеет в 4 тот и в 7 все сможет. А распространение низкое именно потому что он проще в использовании и не заработать на нем, и дифицита нет и продавать не получится адреса.

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

6 такой же как 4… только можно использовать без всяких портов пробросов и прочего… и просто длиннее — нет дефицита… на всех хватает. В чем проблема? Чем сложнее? То что длиннее?

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


И да, то, что длиннее означает, что без DNS уже никак.

И да, то, что длиннее означает, что без DNS уже никак.
Ну как длиннее? Если приватные адреса, то длина под вашим же контролем же. Самые короткие IPv4 приватные адреса:
$ ping 10.1
PING 10.1 (10.0.0.1): 56 data bytes
$ ping 192.168.1
PING 192.168.1 (192.168.0.1): 56 data bytes

Самые короткие IPv6 приватные адреса:
$ ping6 fd00::1
PING6(56=40+8+8 bytes) fd00::1 --> fd00::1
$ ping6 fd00::1:1
PING6(56=40+8+8 bytes) fd00::1 --> fd00::1:1

Самый короткий v4, да, короче самого короткого v6, но следующие уже по длине совпадают.
… использовать с пробросами портов и прочим. То есть просто повторить существующую ipv4 сеть...
Так и да, для небольших сетей, на мой взгляд, оптимально всё тоже самое.
Пробовал как-то ради интереса настроить в локальной сети IPv6, скорее ради потренироваться перед полноценным переходом в будущем, провайдер пока такой услуги всё равно не предоставляет.

Сразу немного поясню, моя домашняя локальная сеть несколько выходит за рамки «обычного пользователя»: несколько L2 сегментов, с отдельными адресами. В чём-то аналог обычных корпоративных сетей: подсеть для пользователей, для серверов, для портов управления сетевыми устройствами, гостевая подсеть, между подсетями настроен файерволл, чтобы разграничить права. Настроено всё это с помощью Mikrotik.
Почему так сложно? С одной стороны, домашняя сеть использовалась как тестовый полигон для изучения IP v4, с другой, я развернул у себя дома небольшой pet-project, который нет причин делать публичным и лишь несколько моих знакомых подключаются к нему по VPN, соответственно, небольшой DMZ мне всё-таки нужен.

Теперь к проблемам.
1. Из документации по IP v6 либо RFC, либо примитивнейшие руководства в стиле «как настроить простейшую домашнюю сеть с помощью stateless», соответственно, чтобы разобраться с проблемами уровня сложнее простейшей домашней сети, необходимо перерыть кучу документации, даже если проблема примитивная.

2. Адресация. Во многом, проблема вытекает из обрывочности сведений. Есть некие Site-local и Link-local диапазоны адресов, при этом один интерфейс в отличие от IP v4 может иметь сразу несколько адресов, имея одновременно белый адрес, site-local и link-local, как при этом ими распоряжаться и что с ними делать на стороне файерволла не очень понятно.

3. Statefull vs Stateless. Stateless весьма неэкономично распределяет адреса (64 бита на адрес, генерируемый на основе MAC-адреса сетевой), кроме того, такой метод конфигурирования работает только для подсетей /64. В сценарии, когда я хочу дома сделать несколько изолированных подсетей, мне надо каким-то образом вымаливать у провайдера аж /48 (ибо так предполагали авторы протокола). Поделить /64 (а мне, как домашнему пользователю вряд-ли дадут больше) на несколько, скажем /72 я могу только при использовании Statefull, при этом о том как его правильно настраивать информации ораздо меньше, чем о Stateless.

4. Тогда появляется другая проблема, в Mikrotik не реализован DHCPv6 для Statefull автоконфигурирования. При этом какие-то роутеры умеют ещё меньше, т. е., с поддержкой IPv6 со стороны оборудования, ситуация, в целом, очень и очень печальная.

До экспериментов с туннельными брокерами в итоге так и не добрался, тот хаос, что получился в локальной сети меня категорически не устраивал и на моменте, когда мне, вероятно, нужно было поднять на виртуалке DHCP v6 и через Mikrotik раздавать адреса с него (вроде такая возможность существует), я свои исследования отложил до лучших времён, которые пока так и не наступили.
Критической необходимости переходить на IP v6 прямо сейчас у меня не было, а дел важнее чем «перенастроить всю локальную сеть непонятно как» было более чем достаточно.

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

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

Итого, большая часть проблем — что выдается всего один /64. Что, как верно указано, совершенно не так, как было задумано.


Но происходит все от недоработки тех самой Legacy обвязки железок у провайдера. Как я понимаю, это должно работать так:


Тот /64, что на внешнем интерфейсе — Stateless и вообще никого не интересует, кроме провайдера, может более-менее произвольно меняться, скажем, при переконфигурации сети и вообще не должен использоваться в качестве адреса для входящих соединений.


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


Но вот всего, что выше — софт операторов просто не умеет и дописывать его никто не будет.

Первый вменяемый комментарий во всей теме.

мне московский Onlime выдаёт /56. И вообще всё чётенько на кинетике работает. Так что жись-то налаживается )

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

> при этом один интерфейс в отличие от IP v4 может иметь сразу несколько адресов

На IPv4, внезапно, то же самое, с самого его начала.

> как при этом ими распоряжаться и что с ними делать на стороне файерволла не очень понятно.

Как раз понятно — вопрос в том, как его настраивают.

В остальном согласен, всё это не дошло до состояния пригодности настройки простым пользователем по 1-3 стандартным сценариям.
3. Statefull vs Stateless. Stateless весьма неэкономично распределяет адреса (64 бита на адрес, генерируемый на основе MAC-адреса сетевой), кроме того, такой метод конфигурирования работает только для подсетей /64. В сценарии, когда я хочу дома сделать несколько изолированных подсетей, мне надо каким-то образом вымаливать у провайдера аж /48 (ибо так предполагали авторы протокола).

Неверно. /64 выдаётся не на адрес, а на всю вашу сеть, на все ваши сервера и локальных клиентов. И в этой сети они уже генерируют себе младшую часть адреса.
Вымаливать необязательно /48. Нет жёстких ограничений и вряд ли авторы это писали. Мой домашний провайдер выдаёт /64 на всю домашнюю сеть, и ещё 7 таких же префиксов, если вдруг мне понадобится настроить несколько сетей /64. В сумме получается /61. Но это не простой провайдер, а гиковский. Другие провайдеры просто выдают /64 на абонента и всё.
Жаль, что этот сайт имеет функционал «выживания» (выдавливания) снобами начинающих пользователей. Вот уже и голосовать запретили. Вместо аргументации тебя просто душат. Таким путём останутся здесь одни убийцы кармы. «Не судите, и не судимы будете.»
Мой провайдер на данный момент вообще не выдаёт IPv6, поэтому я брал произвольную подсеть для экспериментов и пробовал настроить IPv6 внутри локальной сети. Такой вот глупый эксперимент с целью разобраться в новой технологии, не дожидаясь, когда она будет доступна.

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

Признаю, очень неудачно выразил свою мысль. Под неэффективным расходованием адресов подразумевал тот факт, что SLAAC генерирует вторую половину адреса (т. е. 64 бита) на основе 48 битного MAC, 16 бит адреса в таком случае — константа.

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

Была мысль, которую я не проверил, возможно, достаточно было раздать по отдельной сети /64 из диапазона Site-local (fc::/7) каждому из L2 сегментов и настроить файерволл так, чтобы L2 сегменты могли общаться между собой только с использованием Site-local адресов, а с белым IP ходили только наружу.
Но такой подход подразумевал бы раздачу одного блока /64 белых IPv6 сразу на несколько изолированных L2 сегментов (с перемешиванием адресов между ними усилиями SLAAC), что кажется мне слишком странной идеей, чтобы быть правдой.
Не парьтесь за потерянные биты. Человечеству ещё надо дожить до нехватки адресов в этом протоколе. Там оставили ещё несколько нераспечатанных бочек адресов.
Лучше не занимайтесь site-local. Это уже не модно и мало поддерживается. Особенно если у вас не так много офисов, которые нельзя адресовать глобальными адресами.
Главное препятствие для домашних юзеров — это то, что провайдер обычно выдаёт один адрес+префикс и не хочет ничего маршрутизировать на стороне клиента. Поэтому не получается создать несколько локальных сетей со своими раутерами, которые бы имели доступ в интернет. Домашние провайдеры часто выдают только одну конечную сеть и всё.
Это только или если раутер провайдера или ваш личный раутер умеют делать local routing, то в IPv4 это будет работать. А как разбить один префикс IPv6 на несколько, да так, чтобы они нормально работали и в интернет ходили — это уже слишком сложно, это превышает мою компетентность в данном вопросе. Надо более фундаментально изучать протокол и его маршрутизирование. Про SLAAC тоже надо не забывать, где он работает, а где нет.
Жаль, что этот сайт имеет функционал «выживания» (выдавливания) снобами начинающих пользователей. Вот уже и голосовать запретили. Вместо аргументации тебя просто душат. Таким путём останутся здесь одни убийцы кармы. «Не судите, и не судимы будете.»
О, ещё один «угнетённый» и совершенно непонимающий — за что:
Как тут сообщают, эрэфийский джинс (nginx) позорно не умеет работать в double stack.
Мне так кажется, что в эрэфии много таких мест, где окончательным решением шестого вопроса является «завести трактор». Правда, для этого теперь придётся дождаться или выездной визы, или падения железного занавеса, запрещающего ВЫЕЗД граждан из страны РФ.
Ну а что вы ожидали? Когда постепенно душили свободу слова даже в интернете и бешеный принтер печатал всякие репрессионные статьи типа 282, вы же, наверное, не хотели замечать, что этим выжгли националистов. Да так, что слово «русский» теперь уже с оглядкой пишут.
Теперь выжигают разных либералов (не путать с либерастами). Или тех же русских националистов, которые вынуждены прикидываться либералами.
Теперь политруки разных форумов следят, чтобы единственным политически корректным поведением было следование партийной линии правящего режима. То есть, не допускается никакая критика, обратная связь не нужна, если в руках достаточно власти.
Уже ссылка на опыт топикстартера слишком обидная для вас показалась. Ведь неправильные слова были заклеймлены на XXVIII съезде КПСС.
А уж обижаться на совет русскому народу немного приоткрыть глаза и увидеть в какой мрак его ведут — это уже из разряда «Каждый судит в меру своей испорченности».

ПЫСЫ. Я не отрицаю того факта, что в этом году не только русских ведут во всякий мрак, но почти весь шарик, маразма стало больше в разы, многие вещи сгнили и в европе и в америке. Но меня-то более заботил именно русский народ. Или после поездки сайта на тракторе это уже тоже неполиткорректно стало…
>Skype for Business, Microsoft…
Я вам сочувствую. Но причём здесь IPv6?

>Скорость внедрения IP v6 критически ниже скорости исчерпания IP v4 адресов.
Бредятина. Сравнение с нулём. IPv4 общеизвестно уже давно исчерпаны.

>Hurricane Electric
Это не нативный IPv6, а 6to4. Отсюда могут быть свои нюансы.

А еще подумал, что IPv4 идеально вписывает техническую модель функционирования сети в организационную. То есть у провайдера есть НАТ, он отвечает за своих пользователей и его настраивает. У пользователя есть роутер, он отвечает за свои ноутбуки и принтеры и его настраивает. Все понятно, логично, сферы ответственности разделены, в большинстве случаев все само работает, для исключений есть решения. А IPv6 всю эту иерархию размывает со своими белыми адресами. В IPv4 безопасность по умолчанию весьма высокая — ну нельзя через нат пробиться, и всё тут — а в IPv6 она будет низкая — надо отдельно включить файервол, а кто это будет делать? Если его по умолчанию включить, получится НАТ по сути. Если нет — сложная конфигурация — непонятно, кому настраивать и поддерживать.


Вот и не хочет никто этого бардака. Плюс сложно и непонятно.

ну нельзя через нат пробиться

Распространнёное заблуждение. Можно, я проводил живой эксперимент с кинетиком.

Честно говоря, не знаю, как именно, но верю — наверное, можно в некоторых случаях — но это совсем не то же самое, что торчащий в интернет принтер 2005 года выпуска, например. Или домашний NAS.

Достаточно просто иметь включенный файервол. Он защитит и от торчания в интернет, и от пробития нат.


Кстати, в вышеупомянутых кинетиках файервол включен по умолчанию, а для IPv6 отключить его через веб-интерфейс вообще нельзя. Так что с принтерами и NAS всё будет в порядке.


(А вообще было бы интересно глянуть статистику, в каких роутерах файервол включен или отключен по умолчанию)

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

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


соединение точка-точка невозможно.

Вообще для подобного ещё со времён IPv4 существуют штуки вроде UPnP, позволяющие автоматически открывать нужные порты (в кинетике работает, одна моя IP-камера самовольно выставила себя открытым портом в интернет, пришлось UPnP отрубать лол). Правда, кажется, оно не очень распространено, и применяется ли что-то подобное в том же WebRTC, я чёт не знаю

Дык собственно я о чем — киллер-фича IPv6 — белые адреса у всех устройств — практически ни у кого не будет использоваться из-за безопасности, просто скрыто всё будет не за НАТом, а за файерволлом. Разница-то с IPv4 в чем с точки зрения пользователя?


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


Для провайдеров должно быть проще по идее, но видимо, на практике не так.

А как он решит проблему единого адреса для домашней сети? Вот у меня три девайса сейчас имеют проброшенные порты на внешний IP. С любой точки мира, где есть интернет, я могу приконнектиться к веб-серверу, файловой шаре и ssh на роутере. Причём как минимум файловая шара несколько раз переезжала, но внешний адрес: порт не менялись. Формально IP динамический, но 5 лет с первого получения не менялся. Я его наизусть знаю и вхожу по нему. Мог бы и домен какой-нибудь прикрутить, но лень. Как мне такой сценарий использования поднять с ipv6? Домен, допустим, прикручу — запомнить это нереально.

Раздаёте им статику внутри сети и всё то же самое, только порты пробрасывать не надо.

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

Ну да, и что? Либо они будут отличаться последней цифрой либо вы преодолеете свою лень и сделаете web.mycool.name; fs.mycool.name и ssh.mycool.name с AAAA записями.
А ещё можно делать адреса типа 2a02:d3:423f::dea1 или 2a02:d3:423f::dead:beef, круто ведь, согласитесь :)

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

Если вы переживаете за MITMов то там никакой разницы с IPv4 нет.
А при смене провайдера IPv6 мигрируется проще, так как там меняется только префикс, инфраструктура внутри /64 остаётся как была.
Как сказать, как сказать, например в МТС маршрутизатор/модем переподключился и-и-и? Домашняя сеть получила другой префикс, тут то и пошли тормоза. Без DHCPv6-PD жизни вообще нет.

Но все области применения (резервные каналы и прочая, прочая) перекрывают только, либо своя автономная система (AS), либо NAT.

Автор просто смешал с грязью ipv6.


В статье речь идёт, как я понял, во всех случаях о попытках попользоваться ipv6 при его отсутствии. По всей видимости речь идёт о ip6to4, а не о ipv6.


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


Да и не стоит использовать ipv6to4 без острой необходимости. Туннель всегда хуже работает.


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


Это не проблема ipv6, а нежелание копнуть поглубже.


Провайдеры проблемы в своих сетях начнут решать только при массовом использовании. Сегодня в России у топ провайдеров особых проблем не наблюдается. Только несуразные маршруты.


Из моих наблюдений в период COVID-19, по ipv4 трафик в Европу с трудом прорывается, а ipv6 стабильно работает. Возможно связано с иными путями и более новым оборудованием.

Посмотрите результаты опроса, в коментах много похожих историй от грамотных специалистов. Разницы между ip6to4 и ipv6 при 100% наличии соединения без потери пакетов (проверялось через пинг и днс запросы) практически никакой.


Это не проблема ipv6, а нежелание копнуть поглубже.

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

было непонятно, что не так, то настроил роутер (микротик) заново, но без IPv6. Все прекрасно заработало. Всё списал на криворукость коллеги

в числе возможных решений — есть одно 100% работающее — выключить IPv6 на сайте. Выключил — полегчало

Эм. Нет, всё же это именно нежелание копнуть поглубже.

"копнуть поглубже" — это настроить хостинг? там включили ipv6 для галочки и даже когда я пару лет назад попросил дать для каждого сайта отдельный ipv6 адресс — то отказались, сказали что не могут. А при правильной настройке ssl первое, что надо сделать — это обеспечить отдельный ip адрес. К тому же я точно знаю, что для сайтов у них настроено два разных движка — один для картинок и статики, а второй для скриптов, и ещё куча оптимизаций. Так что если и копать — то через техподержку хостинга — а это долго и не факт, что реализуемо. но кучу времени время потратить вполне можно, причем там как принцип домино — потом dkim и прочие настройки почты нужно будет для ipv6 настраивать, короче движений много, а отдачи 0 — при том что есть риски остановки работы сайта и неважно плановые или нет. А прогресс ради прогресса я считаю — что это тупо, обязательно должны быть конкретные преимущества, а не виртуальные "зато более совершенный протокол".

Как на VPS ipv4 адреса закончатся(или просто люто подорожают), так и взлетит, что этот момент наступит, думаю ни у кого не вызывает сомнений. У меня только вопрос, ipv4 у региональных закончились, когда резервы у хостеров то кончатся?
что этот момент наступит, думаю ни у кого не вызывает сомнений.

У меня вызывает и вот почему:


  • IP на VPS в современных облаках уже особо не нужен. Нужен IP на балансер, а их можно сделать существенно меньше, чем VPS.
  • SNI сделал свое дело. 12 лет назад в небольшой компании, в которой я работал, из-за нераспространнености SNI и желания работать через ssl приходилось держать 4 /27 сетки. 5 лет назад я ушел оттуда, и из 4х сеток использовалось не больше 10 IP.

Цена на статический IP4 у хостеров действительно растет (в частности Google повышал), но крайне медленно и пока выглядит вообще смешной. Где один доллар, где 2. У гугла максимум цент в час, а минимум 0.2 цента в час. Например у меня сейчас в облаках на примерно 300-400 VPS израсходовано 7 IP, что обходится примерно в 20 долларов. Очевидно, что у меня все будет финансово сходится и при цене по 50-100 баксов за IP в месяц.


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

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

А что-нибудь, помимо HTTP? ssh через jump host? А остальное?


Цена на статический IP4 у хостеров действительно растет (в частности Google повышал), но крайне медленно и пока выглядит вообще смешной. Где один доллар, где 2. У гугла максимум цент в час, а минимум 0.2 цента в час. Например у меня сейчас в облаках на примерно 300-400 VPS израсходовано 7 IP, что обходится примерно в 20 долларов. Очевидно, что у меня все будет финансово сходится и при цене по 50-100 баксов за IP в месяц.

Дело не только в том, что VPS будут дороже стоить. Хотя сейчас IPv4 составляет заметную часть стоимости дешёвых VPS, например, два доллара от пятидолларовой VPS в Digital Ocean — 40%. Дело ещё и в том, что клиентским провайдерам тяжело купить IP даже под NAT пулы, потому, что их маржа меньше, чем маржа хостеров и, тем более, крупных клаудов.

А что-нибудь, помимо HTTP? ssh через jump host? А остальное?

Это конечно проблема, но небольшая. В основном хосты ставятся под http. У нас же эра, когда все запихивают в http. Т.е. ssh не особо нужен. А доступ к ssh виртуалок и так лучше через vpn делать.


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

Ну выше человек говорил про VPS, и мой посто только про VPS. Что касается мелких провайдеров, то здесь истории 2. Во-первых, мелкие провайдеры поглащаются крупными во всем мире и в РФ в частности (сам в этом процессе активно участвовал). Поэтому в РФ у пройдеров реального острого дифицита сейчас не наблюдается. Есть проблема в разрушении иерархии выделения IP, но тут рынок зарешает со временем и начнутся продажи от одного другому, как прижмет. Во-вторых, есть страны, на которых изначально пула не выделили, где реальная проблема, но таких не очень много. Мне кажется именно эти страны, плюс условная Африка могут стать драйверами роста для IPv6. Но это тему я не готов обсуждать — мне она не ясна.


Откровенно говоря, как в прошлом админ, а теперь начальник в небольшой разработческой компании,