Комментарии 46
Это все не обязательно! Меня сейчас наверное побьют в комментах, но я скажу страшную вещь - если вам просто надо, чтобы у ваших клиентов была IPv6-связность с минимальными усилиями, простой настройте такой же NAT для IPv6, как вы это делали для IPv4, и пусть они все выходят в интернет с одного адреса (это называется NAT6). Да, не красиво, да, не используются все возможности, но оно настраивается одной командой и сразу работает.
Бить особо не собираюсь. К тому же мы находимся в ситуации, когда инструментами чиним сеть, которую кто-то сломал. Поэтому я не против NAT. Но при использовании IPv6 нужно учитывать одну вещь. Нельзя просто так взять и назначить клиентам адрес из диапазона fd00::/7 и ждать что у всех всё заработает. Некоторые клиенты не будут пользоваться IPv6 по той причине, что сеть fd00::/7 не маршрутизируется в интернете, а значит использовать адрес из этого диапазона для исходящего соединения на публичный адрес бессмысленно. Поэтому к вашему NAT теперь придётся ещё и прикрутить какую-то фиктивную адресацию с GUA адресами, чтобы у клиентов всё заработало. В такой ситуации вообще непонятно зачем нам использовать NAT, если мы и так будем выдавать GUA адреса клиентам. Разве что NAT нужен, чтобы сокрыть реальный адрес клиента... Короче, тут NAT не для функционирования сети нужен, поэтому я такое вполне допускаю.
Мол, если мы получаем от хостера префикс, то надо и каждому клиенту раздавать индивидуальные адреса из этого префикса, и тому подобное. После настройки, как правило, ничего не работает, потому что у хостеров обычно не-routed префиксы и нужно использовать что-то типа radvd.
radvd тут совершенно ни при чём. radvd рассылает анонсы машрутизатора в сеть, которые нужны для автоматического конфигурирования IPv6. Для того же Wireguard он совершенно бесполезен.
Проблема тут в другом. Провайдерский маршрутизатор при запросах извне на вашу адресацию посылает вашему серверу запрос - «кто там у нас владеет этим адресом?». Если вы не присвоили этот адрес вашей машине на интерфейс, который смотрит в сторону провайдера, то ваша машина отвечать не будет. У неё же нет этого адреса. Нам нужно заставить нашу машину отвечать на запросы поиска соседей. Этим занимается ndppd. Он проксирует запросы поиска соседей туда, куда мы скажем, или вообще просто будет отвечать безусловно, что да, это мой адрес и шли мне все пакеты для этого адреса. А ещё NDP proxy можно настроить через sysctl, но я глубоко в тему не вникал.
Вообще, IPv6 у разных провайдеров по разному настроен. Нужно индивидуально смотреть каждого. Но почти для всех есть свои решения, кроме разве что тех, кто поштучно раздают IPv6 адреса. От таких провайдеров надо уходить.
Некоторые клиенты не будут пользоваться IPv6 по той причине, что сеть fd00::/7 не маршрутизируется в интернете, а значит использовать адрес из этого диапазона для исходящего соединения на публичный адрес бессмысленно.
Там вроде как довольно много всяких зарезервированных диапазонов. Некоторые из них уже не рекомендуются к использованию, но на современных ОС работают и обеспечивают связность без проблем при назначении их клиентам, всякие там fec0::/10
radvd тут совершенно ни при чём. radvd рассылает анонсы машрутизатора в сеть, которые нужны для автоматического конфигурирования IPv6. Для того же Wireguard он совершенно бесполезен.
В обратную сторону. Чтобы когда из внешнего интернета кто-то решит послать IP-пакет в ответ вашему клиенту, этот самый пакет с оборудования хостера в дата-центре прилетел к вам на VPS, а не куда-нибудь ещё. Возможно для этого действительно достаточно ndppd, но я встречал инструкции именно про radvd
ravdv - это ничто иное как Router Advertisement Daemon, т.е. демон, который обеспечивает рассылку анонсов маршрутизатора. Это нужно только в сетях, где вам необходимо автоматическое конфигурирование клиентов. Если вы используете Wireguard, то он вообще, в силу своей простоты, никак с этим работать не может. OpenVPN обычно раздаёт адреса из указанного ему диапазона. Т.е. для него radvd не нужен. Может быть их как-то и можно скрестить, но и без него всё работает.
В нашем случае нужно не анонсами маршрутизатора заниматься, а обеспечивать пересылку на себя пакетов с помощью механизма поиска соседей, раз провайдер не смаршрутизировал их на вашу машину. А для этого нужен именно NDP proxy. ndppd - один из вариантов реализации.
Там вроде как довольно много всяких зарезервированных диапазонов. Некоторые из них уже не рекомендуются к использованию, но на современных ОС работают и обеспечивают связность без проблем при назначении их клиентам, всякие там fec0::/10
Unique local address-диапазоны, а fec0::/10 относится именно к таким, при обращении к GUA-адресам имеют приоритет ниже, чем IPv4. Можете хоть нерабочие адреса выдавать клиентам VPN, чтобы они вообще не пытались использовать IPv6.
https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/
https://blog.ipspace.net/2022/05/ipv6-ula-made-useless.html
Не знаю, как ULA на одном интерфейсе и GUA на другом поведут себя при наличии двух маршрутов по умолчанию, нужно проверять.
UPD: проверил, при такой конфигурации будет использоваться интерфейс провайдера (не VPN), даже если метрика у маршрута по умолчанию через VPN ниже. ULA добавляются только со scope: site.
Я недавно писал ndp proxy себе для VPN. Алгоритм работы примерно следующий:
отслеживается conntrack и если адрес (src или dst) попадает в указанную сеть периодически (10 секунд) выполняется unsolicited neigh advert этого адреса с mac интерфейса.
unsolicited neigh advert прекращается если событий conntrack для этого адреса не было 1 час.
прослушивается трафик neigh solicit и при получении запроса из искомой сети отправляется ответ с mac интерфейса.
периодически (10 секунд) отсылается neigh solicit на default gw и при получении ответа обновляется его адрес в таблице - сделано скорее для надежности и почему-то на одном из хостингов сеть /80 и мак gw часто пропадает.
могу немного причесать и выложить на github если кому-то будет полезно...
У меня провайдер не поддерживает ipv6, использовал туннель поверх ipv4. Несколько месяцев бился с прошивкой Keenetic-а и надоело. На самом роутере все работает, проходят пинги v6, а клиент выдает "общую ошибку" на интерфейсе. В какой-то момент начинает работать, а через неделю отключили свет и все по новой. Разные версии прошивок, разные клиенты (win8,10,11). Может быть тоже какая-то ошибка в некоей популярной нынче библиотеке... А вот на старом Asus с кастомной прошивкой кажется 2013 года ipv6 работал как часы, но роутер тот устал и сказал "я больше не могу".
IPv6 не просто замена IPv4, он еще отменяет ARP и использует NDP (aka NP), который использует подмножество сообщений ICMPv6. Если ICMP заблокирован то... вот еще один вариант выстрелить себе в ногу.
NDP позволяет адаптеру самому себе выбрать случайный адрес из соответствующего диапазона для локальной связности - это т.н. local-link адреса, они не раутятся. Поэтому если вы видите только один IPv6 на адаптере - это верный признак отсутствия раутров по IPv6.
NAT для IPv6 - это скорее gateway в IPv4 мир и обратно, чем его аналог в IPv4 мире. Т.е. трансляцию IPv6 в IPv6 (обычно) никто не делает. А IPv6 -> IPv4 конечно делают.
Перехват SNI - норм. но только если это не ESNI. И Retry Client Hello одычно криво обрабатывают...А они возникает если сервер не поддерживает нужные клиенту cypher, что например возникает если клиент на openssl 3.0, а сервер на openssl 1.1. Казалось бы. И там и тут TLS 1.3, но retry.
NAT в IPv6 не делают, а вот замену префиксов могут. У меня на домашнем шлюзе де-факто три внешних адреса: у локального провайдера и два тоннеля. С IPv4 это более или менее удалось настроить, чтобы работало, а c IPv6 просто 🤦🏻♀️
И еще одна особенность - если по пути есть шлюзы или туннели, то они налагают не вполне очевидные клиенту ограничения на MTU и трафик может резаться, особенно если фрагментация запрещена или не обрабатывается корректно.
Т.к. IPv6 заголовок сам по себе больше, чем IP, то и MTU ниже.
Есть конечно, RFC 8201 - MTU Discovery, но для его работы требуется всё тот же старый новый ICMPv6.
Годы идут, а пользоваться IPv6 всё ещё проблемно. И так наверное продлится ещё столько же лет, сколько уже внедряется IPv6 (уже в разы дольше, чем IPv4 существовал на момент появления IPv6).
А всё почему? Потому что социальные, организационные процессы побеждают технические вопросы. Чтобы на новую систему люди хотели перейти, она должен работать не хуже старой и полностью заменять старую. Но это невозможно, потому что новая система будет работать хуже и не полностью заменять, пока все не перейдут. В итоге, у нас получается не замена, а добавление. И даже если каждая из систем могла в теории работать хорошо, но добавляется ещё и стык между ними со своими багами.
В итоге имеем то, что имеем: нужно поддерживать полную работоспособность старой системы, новой системы и стыков между ними. Что естественно в три раза сложнее и больше проблем. Самый наглядный и дорогой урок о невозможности и последствиях хард-форков в децентрализованных системах, которые ты не полностью контролируешь. Только эволюция, только плавный переход с обратной совместимостью.
Годы идут, а пользоваться IPv6 всё ещё проблемно. И так наверное продлится ещё столько же лет, сколько уже внедряется IPv6 (уже в разы дольше, чем IPv4 существовал на момент появления IPv6).
Вы совершенно неправы. IPv6 способен полностью заменить IPv4. Сдерживающим фактором является именно засилие IPv4 в сети. Настройке IPv6 не все уделяют достаточного внимания и, например, я на сервер в Новосибирске хожу из Новосибирска с Ростелекома через Москву (вполне вероятно у них там ТСПУ). Но если сеть настроена корректно, то и IPv6 работает ничуть не хуже, а возможно и лучше, чем IPv4.
Свой вклад вносят и провайдеры хостинга. Совершенно недавно на мой запрос о том, что есть некоторые проблемы с потерями пакетов IPv6 долго поддержка не отвечала, а потом сказали, что они первые кого атаковали по IPv6 и, типа, всё наладится позже. Ок. Мне не критично, подожду. Тем более веб-сервер вполне себе удовлетворительно отвечает и справляется. А позже получаю совет использовать IPv4, чтобы всё стабильно было. Т.е. они совершенно не заморачиваются решением проблем в со своей сетью, а IPv6 у них для галочки.
Если у вас есть внешний NAT64, то можно пользоваться всем интернетом исключительно через IPv6 и практически не испытывать никаких проблем. А те проблемы немногочисленные, связаны не с протоколом IPv6, а с ресурсами на IPv4, поскольку в таком варианте не работает без дополнительного костыля обращение к IPv4 адресу напрямую. Но и это лечится через clatd на linux, а в Windows 11 обещали его добавить в ближайшее время. Но никто не заставляет вас использовать только IPv6. К тому же этот костыль можно на машрутизаторе, если у вашего провайдера сеть только на IPv6.
Ещё одним сдерживающим фактором является то, что поддержку IPv6 в своих устройствах часто многие производители делают формальную. Т.е. да, устройство может работать с IPv6 адресами. Но построить на нём что-то сложнее сети, которая раздаёт сеть /64 невозможно. Например, такие CPE под брендом Ростелеком. У них даже нет встроенного файервола для IPv6, либо он включен по умолчанию и никак не настраивается (увы этого я не успел проверить, а сейчас использую нормальный маршрутизатор). Но это небольшая проблема. Если я получаю на нём свою сеть /56, то я совершенно не могу раздать выданные мне 256 сетей кому-то ещё. Одну сеть /64 он раздаёт через LAN интерфейсы. А остальные 255 сетей висят мёртвым грузом и никак не используются. Но всё меняется, если поставить нормальный маршрутизатор с полноценной поддержкой IPv6.
Резюмируя. Каких-то явных проблем у IPv6 протокола нет. Он способен полностью заменить IPv4 и работает не хуже, а возможно, даже и лучше, за счёт более эффективного распределения адресного пространства по территории планеты и более простой обработки пакетов на промежуточных узлах. Но откуда проблемы? Саботаж по внедрению протокола и недостаточное уделение внимания настройкам своих сетей для работы с IPv6.
Вишенка на торте. Google - чемпион по внедрению IPv6. Если заходить на www.google.com или открывать ссылки в их почте Gmail по IPv6, то придётся периодически столкнуться с капчей и доказывать, что ты человек, а не робот.
То, что вы называете "засильем IPv4" я и все простые пользователи и многие создатели сети (те самые провайдеры, которые почему-то не хотят тратить ресурсы на то, чтобы добавить к одному работающему решению ещё одно, работающее наполовину) называем "рабочим интернетом".
К протоколу вопросов нет, вопросы именно к тому, что Интернет в целом -- это не протокол, и не чисто техническая система, это социо-экономическая система, состоящая из техники, людей, бизнесов и т.д. Обратите внимание, как в вашем ответе просто все категории имеющие отношение к интернету почему-то не горят особым желанием его внедрять. И провайдеры плохие, и пользователи плохие и производители железа поддержку формальную делают и даже чемпионы по внедрению заставляют капчи разгадывать. А простите, из кого ещё сеть состоит? И ради кого мы все должны сверкая пятками бежать внедрять новое, "технически рабочее" решение поверх практически рабочего?
Именно поэтому я и написал, что попытка насадить "более совершенное" административным порядком на независимых, децентрализованных системах -- чаще всего проваливается. Теперь-то уже точно понятно, что правильным было бы добавить пару байт к адресу (что NAT по сути и осуществил, переведя номер порта в часть адреса, без изменения протоколов, просто изменив семантику обработки) и создать аукцион на IP адреса, чтобы обеспечить рациональное распределение (кому больше нужно, тот способен больше заплатить, а деньги пойдут на дальнейшее развитие сети).
Вместо этого, получили ситуацию, когда IPv4 всё равно критически нужен и отключить его невозможно и адреса продаются на аукционе. IPv6 тоже теперь нужен, потому что половина успела на него перейти. И стык тоже нужен, потому что ни одна из систем без другой работать не может. И проблемы никуда не денутся, потому что одной или другой системе будет уделяться меньше внимания (сначала никто не хочет вкладываться в приходящий IPv6, потому что ещё рынок маленький, потом никто не будет хотеть вкладываться в уходящий IPv4, потому что вот же система будущего, почти рабочая, осталось только чуть-чуть поднажать). В итоге проблемы будут на всём протяжении пути, хотя технически-то оба протокола просто замечательные.
А внедрять не хотят потому, что худо-бедно всё и так работает, а при полном переходе неизбежно отвалится часть клиентов.
Вы пишете, что внедрять не хотят. Не из-за несовершенства ведь, и не из-за сложности, и не из-за цены. Просто все вынуждены смотреть друг на друга и никто не может сделать этого полностью. Вот и остаётся постепенно добавлять в6 к существующим системам.
А всего парой байт к адресу там бы не обошлось. Да и в аукционе нет ничего хорошего - стоимость адресов неизбежно снизит гибкость настройки сети для тех, кому это действительно нужно
например, я на сервер в Новосибирске хожу из Новосибирска с Ростелекома через Москву
мне хабравчане доказывали, что подобное как раз хорошо, так сеть может работать при разрушенных звеньях, а также скрывать фактическое физическое положение узла
IPv4 это классическая проблема "дохлой лошади". Он исчерпал резервы расширения, он тормозит развитие, уже двадцать с лишним лет существует новое решение и оборудованиея его поддерживающее, но люди все равно продоожают ездить на дохлой лошади, нарушая известное правило.
Только сотовые операторы смогли внедрить IPv6 из-за выстроенного процесса замены оборудования. В коммутаторах ещё 5 лет назад его поддержка была премиальной фичей не для каждой модели, а с фактической реализацией всё плохо до сих пор.
Нас спасёт требование поддержки IPv6 для новых систем, как делает Apple или законодательство в Скандинавии и США.
Ну как исчерпал... если отключить IPv6, то ничего не отвалится и можно даже не заметить, что он отключен (разве что по тому что всё надежнее работать станет, ха). Следовательно, до настоящего времени мы с ним как-то дотянули.
Просто ipv6 придумали идеалисты которые сделали хорошее решение. Но хорошее решение всегда проигрывает баблу. И половина интернета не готова выбрасывать свой софт, который зачастую работает только с ipv4 или плохо с v6, ради идеалистов. В целом я с ними согласен - если софт написали 20 лет назад, последние 10 лет он обкатан и без поддержки работает с v4, то зачем мне выбрасывать прибыльный безпроблемный актив и платить разработчикам за софт который мало того что не окупится, так ещё и проблемы принесёт.
Тут самоподдерживающийся процесс: пока IPv4 кто-то использует — IPv4 будет жить, а пока IPv4 жив, его будут использовать) В таких условиях ряд провайдеров и хостеров попросту решит не тратить деньги на внедрение нового стандарта, если всё и так работает, а пользователи разницы всё равно не заметят. Если говорить о России, то тут ещё и политический момент. Новая технология усложняет контроль за пользователями (IPv6, HTTP/3)? Значит не будем её внедрять, а то и вовсе заблокируем.
В общем, нужны драконовские меры сверху, как в Европе с принудительным переводом всех производителей, включая Apple с их проприетарщиной, на USB-C. Без этого не сработает. Кстати, в той же Европе недавно приняли план об обязательном повсеместном внедрении IPv6, но Европа это ещё не весь мир.
Вот начало рассуждения верное, а вывод всё равно про сильную руку. Задайте себе вопрос: зачем всем этим людям и организациям нужно навязывать новое, якобы гораздо более хорошее решение драконовскими мерами? Почему оно не может само распространиться?
И вы действительно хотели бы, чтобы кто-то пришёл лично к вам и сказал: "так, нужно выкинуть всю вашу старую компьютерную технику, потому что она не поддерживает новый стандарт или поддерживает его недостаточно хорошо"? А провайдер отключил бы IPv4, потому что его настойчиво попросили. А если вы не смогли бы подключиться куда-нибудь, то это ваши проблемы, потому вы, со своим желанием зайти на сайт, автор которого оплатил его на сто лет вперед, а потом умер или ушёл в монастырь, мешаете прогрессу и движению в светлое будущее?
кто-то пришёл лично к вам и сказал: "так, нужно выкинуть всю вашу старую компьютерную технику, потому что она не поддерживает новый стандарт или поддерживает его недостаточно хорошо"?
Справедливости ради, отмечу, что IPv6 уже 30 лет. И техники, которая его прямо вот никак не поддерживает — ещё поискать надо. Уверен, что и магистральное оборудование провайдеров и подавляющее большинство пользовательских устройств прекрасно поддерживают "новый" протокол
Но хостеры не все поддерживают IPv6. Особенно удивил в этом плане Яндекс со своим облаком. IPv6 нет и как включить не нашел (надо будет ТП спросить после праздников, послушать что скажут на эту тему)
Здравствуйте! Я из Яндекса, хочу помочь разобраться.
В Yandex Cloud возможность работы с протоколом IPv6 не реализована на уровне Yandex Virtual Private Cloud, то есть, на уровне сети для всех облачных сервисов. Вы можете проголосовать за добавление этой поддержки этого протокола в разделе «Сообщество».
Возможно, вариантом выхода может быть реализация серверной части вашего приложения вне Yandex Cloud. С одной стороны такой сервер будет принимать подключения клиентов в Dual-stack по IPv4 и IPv6, а с другой — передавать данные на обработку в Yandex Cloud Functions по IPv4.
Подробнее можно прочитать в документации: https://ya.cc/t/ZR-6A_VU4zZuYb
Ну так речь про то, что должны были прийти тридцать лет назад и заставить всех переходить на "правильный" протокол. Когда ещё едва оперились первые провайдеры и хоть какой-то бизнес в сети начался (а до расцвета ещё десятилетия), а тут пришли бы регуляторы и запретили бы IPv4.
Только я думаю, что после такого манёвра мы бы увидели не расцвет IPv6 и как там выше говорили про "повышенную гибкость" и т.д., а разрушение зарождающейся индустрии на десяток-другой лет.
Уверен, что и магистральное оборудование провайдеров и подавляющее большинство пользовательских устройств прекрасно поддерживают "новый" протокол
Только провайдеров пинать надо. В Новосибирске никто из доступных мне провайдеров не предоставляет IPv6. Есть Дом.ру, который предоставляет, но он не везде доступен. Но по факту оказалось, что на Ростелекоме очень даже есть IPv6. Да ещё и не просто есть, а в большинстве регионов присутствия. Но они совершенно не хотят им заниматься! Официально его НЕТ и поддержка никак не поможет, если есть проблемы. Но при этом он почти полноценно работает если не считать кривых маршрутов (пинг из Новосибирска в Новосибирск через Москву, больше 50 мс) и некоторых проблем в единичных регионах.
Также проверять остальных провайдеров желания нет. Может быть у кого-то есть ещё... но официально нет ни у кого. Периодически обзваниваю всех доступных мне и ничего не меняется. Некоторые сразу говорят, что даже не планируют.
Из сотовых только у МТС и Мегафон, но у них и тарифы дороже раза в 2, чем у конкурентов. Yota приняли пожелание (по сути послали), Tele2 даже не планируют. Билайном не интересовался. У Мотива тоже вряд ли есть, но нужно проверять.
Привет! Мы вовсе не забываем про пожелания пользователей и стараемся реализовывать их. Увы, не всегда сроки получаются короткими :( Постараемся порадовать вас появлением технологии как можно скорее.
Вот ещё один аспект пришёл в голову после вашего ответа. Работающие системы -- это капитал, это многочисленные ресурсы: труд, деньги, время и т.д., вложенные за долгие годы. Причём аспекты этого "капитала" и вложенные ресурсы могут быть совершенно не очевидны -- каждый работник техподдержки, который умеет настраивать один протокол или другой, каждый просто пользователь, который знает "192.168.0.1/24" пусть даже как магическое заклинание -- это понесённые затраты, это время потраченное на то, чтобы понять как это работает.
То есть мы имеем огромное количество невидимых усилий, которые создали то, что работает. И приносить поверх несовместимое новое, да ещё и просто на порядок сложнее (реально: знаю кучу людей, кто казуально разбирается в том, как работает IPv4, и ни знаю никого, кто бы понимал нагромождение IPv6 адресов, префиксов, роли роутеров и т.д., если не работают сетевиками), практически "про запас", чтобы избежать потенциальных проблем (как пишут выше: "снизит гибкость настройки сети") -- это по сути предлагать выбросить накопленный капитал и заплатить второй раз, чтобы получить тоже самое. Но в жизни получилось ещё хуже -- и выбросить не получилось, и заплатить второй раз придётся и получается в итоге ни рыба, ни мясо.
Да не такой уж и большой объём знаний там нужен. Те, кто разбираются в IPv4 легко поймут как работает IPv6. А кто слабо разбирается, тому вообще особо разбираться не надо будет, ибо в IPv6 автоматизация есть и все эти вбивания, аналогичные 192.168.1.1 даром не нужны.
А вот отказ от IPv4 позволяет отказаться от разных костылей, которые помогали решить нехватку IP адресов и решать проблемы, вызванные этими решениями...
Уже есть провайдеры, которые предоставляют IPv6. Значит у них есть оборудование, которое способно работать только с IPv6. Это вполне решаемая задача на относительно современном оборудовании (10-15 летнем точно).
Построить домашнюю или корпоративную сеть на IPv6 проще простого, если конечно вы не используете технику из нулевых годов. Есть проблемы с софтом, но они все решаемые, если вендор не бросил поддержку железки. А если на железку можно поставить альтернативную прошивку на базе, например, OpenWRT, то у вас вообще не будет проблем с IPv6. Я в 2016 году покупал самый дешёвый маршрутизатор Asus. Там уже вполне поддержка IPv6 была на уровне, достаточном, чтобы раздать этот самый IPv6 в твоей локалке. И я даже раздавал их в 2016 году через туннель. От провайдера он тоже сможет раздать. А больше он ни на что и не годится, ибо железо очень слабое.
Никто не заставляет сразу 100% пользователей переводить на IPv6. Можно внедрять постепенно. Только лучше учитывать, что построение сети на базе только IPv6 проще, а пользователь даже может не заметить, что в вашей провайдерской сети вообще нет IPv4 (кроме шлюзов для этого протокола). И этим активно пользуются Европейские провайдеры. При этом по мере внедрения IPv6 в интернете нагрузка на их шлюзы будет падать, а вот нагрузка на костыльные решения для IPv4 с годами только растёт. Так что внедрение IPv6 окупится в дальнейшем, например, часть оборудования можно будет просто снять и не нужно будет его заменять.
Дело не только в знании банальностей "о, вот есть адрес", дело в знании тысяч нюансов -- и про сам протокол, и все сопутствующее, что поменялось и про то как это работает (и главное -- ломается) в реальной жизни.
Отказ от IPv4 невозможен, просто примите это как факт, как реальность данную нам в ощущениях. И исходя из этого надо понимать, что невозможен отказ от костылей IPv4. И следовательно нужный объём знаний теперь включается в себя минимум 3х, не смотря на то, что "всё само настраивается". Если не больше: теперь надо понимать v4, v6, их стык, туннели в одну сторону, туннели в другую, современную версию этих туннелей, nat66/64/46/88, что из перечисленного поддерживает ваша собственная техника, что поддерживают провайдеры на каждом из уровней, что поддерживает сервер/хостинг. И всё время будут какие-то неожиданные нестыковки (см. обсуждаемую статью) в которых как бы никто не виноват, и которые в то же время можно было бы "просто" решить, если бы все вдруг одновременно перепрыгнули в будущее.
Отказ от IPv4 невозможен, просто примите это как факт, как реальность данную нам в ощущениях.
А что мешает отказаться от него? Что сломается? Да, единственная причина - легаси устройства. Но для них можно островок IPv4 поднять и пользоваться дальше. Нет в IPv4 чего-то такого, что нельзя сделать в IPv6!!!
Все современные мобильные устройства прекрасно работают с IPv6. Все системы семейства *nix работают с IPv6 без ограничений. И там даже есть костыль для того, чтобы не имея IPv4 адреса на сетевом интерфейсе заставить работать программы, которые плюют на всё и пытаются подключиться именно по IPv4 адресу (например, торренты, потому что пир на IPv4). Даже в Windows обещают добавить подобный костыль. А уж с IPv6 WIndows прекрасно работает со времён Windows 7. На Windows XP не проверял, возможно там есть проблемы. Но, извините, эту систему уже официально списали много лет назад!!! Да там и интернетом уже нельзя нормально пользоваться.
Нет никакой нужды сохранять IPv4 протокол в глобальной сети! Я вполне могу сказать зеркально, что это нужно принять как факт, как реальность данную нам в ощущениях.
P.S. Отправил это сообщение и понял, что оно ушло с моего компьютера на сайт habr.com по IPv6 протоколу. Но, поскольку на habr.com не поддерживается IPv6, то этот запрос ушёл туда через внешний шлюз NAT64. Вот такая суровая реальность.
Вот давайте мы зеркально откажемся: я от IPv6, вы от IPv4 и посмотрим, чья реальность сильнее. Готов заключить пари на $100: и через десять лет, всё ещё можно будет ходить в сеть исключительно через IPv4 и что-то будет ломаться на исключительно IPv6 :)
"что мешает отказаться от него" -- то, что он работает, то, что называемое вами "легаси" -- люди называют "работающей техникой". Вы посмотрите на приведённый в статье график (оригинал): медленно, постепенно дошли за 15 лет до доли в 40-45%. Это значит, что по всему миру большинство пользуется IPv4, а вы говорите "легаси". А если по странам карту открыть, то ещё интереснее ситуация: несколько богатых/продвинутых или наоборот, бедных/продвинутых (тех кто начал массово строить интернет уже в эпоху IPv6) тянут среднее вверх, но по многим странам там в районе нуля-единиц процентов распространение. И как вы предложите "изолировать островок IPv4"? Отключить Россию, Турцию, Китай, всю Африку? Заставить их выбросить/обновить всю инфраструктуру одним днём? Вы понимаете, что "глобальная сеть" -- это все те миллионы длинков, разбросанных по чердакам и подвалам многоэтажек по всем этим странам? В дополнение с сотням тысяч серверов в случайных серверных на тысячах предприятий, которые уже стоят и работают и выполняют свои задачи и трогать которые только ради того, чтобы убедиться, что они работают через IPv6 никто не будет?
Процесс идёт конечно -- старые устройства ломаются, выходят из эксплуатации, старые спецы выходят на пенсию, дефолты меняются и скоро уже нужно будет активно ломать настройки, чтобы от IPv6 отказаться. Вот тогда, в этом светлом будущем, лет через 20 мы может и проведём День Отказа от IPv4 под эгидой ООН, но потом ещё лет 10-20 будем поддерживать, потому что что-нибудь будет продолжать отваливаться, совершенно неожиданное.
Это значит, что по всему миру большинство пользуется IPv4, а вы говорите "легаси".
Я не говорил такого об IPv4. Я говорил об устройствах, которые не умеют работать с IPv4. Вот для них и нужны островки IPv4. У меня, например, есть два Zigbee шлюза от Xiaomi и Aqara. По функциям они идентичны и ни один не умеет работать с IPv6. Но всё меняется, когда на Aqara ставится альтернативная прошивка. Я теперь прекрасно работаю с ним по IPv6. Допускаю, что у других есть и IP-камеры и другие устройства, поддержка которых прекращена, а поддержка ими IPv6 не была добавлена. Я об этом говорил!!!
Вот давайте мы зеркально откажемся: я от IPv6, вы от IPv4 и посмотрим, чья реальность сильнее.
Будете смеяться, но я сейчас оказался в ситуации, что у меня дома не работает IPv4 адресация. Немного задерживается зарплата и Ростелеком отключил мне за неуплату IPv4. И не сразу замечаешь, что с интернетом что-то не так, потому что Youtube продолжает работать как ни в чём не бывало. Многие сайты открываются без проблем. Ну, например, можно продолжать пользоваться сервисами Yandex. Большую часть вопросов с ресурсами IPv4 я снимаю с помощью внешнего NAT64. В обычном режиме он у меня свой на маршрутизаторе и устройства внутри моей домашней сети могут работать исключительно на IPv6. Я даже специально ради эксперимента перевёл стационарный компьютер исключительно на IPv6. И у меня там не возникает никаких проблем. Так что прежде чем я написал свои комментарии я уже попробовал жить в мире IPv6.
Вот давайте мы зеркально откажемся: я от IPv6, вы от IPv4 и посмотрим, чья реальность сильнее.
Про отказ от IPv6 - смешно :-D У нас почти вся страна сидит исключительно на IPv4. Провайдеров минимум, кто IPv6 предоставляет. Официально предоставляет ещё меньше. Странно думать, что в таких условиях кто-то что-то будет предоставлять исключительно на IPv6.
Готов заключить пари на $100: и через десять лет, всё ещё можно будет ходить в сеть исключительно через IPv4 и что-то будет ломаться на исключительно IPv6 :)
Я не азартный человек. И к такому пари много вопросов. Например, по какой стране будем оценивать? Китай активно внедряет IPv6 и в 2030 планирует отказаться от IPv4. В Индии процент подключений с IPv6 больше 60%. Европейские провайдеры переводят свою инфраструктуру исключительно на IPv6. Чехия вообще заявила, что прекратит предоставление государственных услуг по IPv4 6 июня 2032 года. И, в то же время, в РФ вряд ли что-то будет меняться, потому что в условиях санкций не до развития сети. Мне не ясны критерии, по которым будет считаться, что я победил в этом споре.
Мне нравится ваш реализм: "ну, в принципе, многие сайты открываются, чего же более желать" :) Вы спрашиваете в прошлом комментарии "что мешает отказаться", а в последнем приводите целый перечень причин.
Например, по какой стране будем оценивать?
Да по произвольной. Вот вы пишете, что Китай активно внедряет и планирует отказаться от IPv4 к 2030, а я готов поспорить, что в в 2034 году IPv4 будет в Китае ещё жив :)
IPv4 будет в Китае ещё жив :)
Что значит «будет жив»?
Если от IPv4 откажутся государственные сайты, означает ли это, что IPv6 победил?
Если большинство провайдеров будет предоставлять как минимум дуалстэк, можно ли считать это победой IPv6?
Если провайдеры массово перейдут на IPv6 для построения своей сети, чтобы упростить её, а для доступа к ресурсам IPv4 поставят NAT64, это победа?
Если я сейчас дам ссылку на провайдеров, которые используют MAP-T у себя на сети, то будет ли это считаться досрочной победой?
Вы не подумайте, что я какой-то противник новых технологий или IPv6 в частности. Я просто выдвинул тезис, что переход на IPv6 был задуман и осуществлён максимально коряво и все потенциальные минусы IPv4, которые должны были его оправдать либо не осуществились, либо никуда не денутся. Поэтому "победа" IPv6 невозможна, возможно лишь постепенное уменьшение страданий от его внедрения :)
Если в Китае будет хотя бы 5% доменов с одной А-записью, без АААА то это будет значить, что IPv4 ещё жив, вне зависимости от того, какие костыли поддерживают его существование, шлюзы ли, наты, дуал-стек, что угодно.
у меня сложилось стойкое ощущение, что ipv6 — штука хорошая, но не для последней мили.
замечательно работает внутри крупных кластеров (говорят, внутри яндекс.облака, например, чистый ipv6). Хорошо подходит для магистралей.
Для последней мили же… Я сдался и поотключал у себя везде. Просто потому что я не получаю ни одного преимущества от его наличия, зато проблемы — регулярно.
Судя по всему, глюк есть только в версиях для iOS (по крайней мере, большинство жалоб именно от пользователей Apple). Учитывая, что оба приложени разработатываются одной компанией, весьма вероятно что там используется одна и та же библиотека или один и тот же код, и в нем есть этот баг.
Разве приложениям в iOS дозволяется самостоятельно реализовывать сетевой стек? Даже если использовать какие-то библиотеки для работы с сетью, у них под капотом все равно будет системный NSURLConnection.
Причина тормозов скорее всего связана с работой антибот-системы на бэкенде. Для подозрительных коннектов просто ограничивают кол-во запросов в единицу времени, вот и все.
Причина тормозов скорее всего связана с работой антибот-системы на бэкенде. Для подозрительных коннектов просто ограничивают кол-во запросов в единицу времени, вот и все.
В таком случае проблемы с IPv6 на это слабо бы влияли. А эксперименты показывают, что дело действительно в IPv6, автор Streisand даже был вынужден добавить IPv4-only режим (раньше у него IPv6 был включен по умолчанию) в клиент, потому что его забрали сотни людей ноющих про whatsap/Instagram и утверждающих что это его баг; может, конечно, антибот у них агрится только на IPv6, но тогда бы проблемы были и на android тоже, а пока что 99% жалоб идёт с iOS- устройств
IPv6, собственно, и появился, когда стало ясно, что устройств, подключенных к интернету, в мире становится сильно больше, чем доступных адресов, а городить костыли в виде NAT'а бесконечно не получится и надо что-то с этим делать
и тут же
чтобы у ваших клиентов была IPv6-связность с минимальными усилиями, простой настройте такой же NAT для IPv6
и тут же
Тогда можно сделать так: установить на сервер DNS-сервер (например, dnsmasq)
По секрету, dnsmasq — не только dns, но ещё и dhcp сервер. С поддержкой IPv6. Который умеет в PD. Чем писать сомнительности про NAT66, лучше бы написали как запустить dnsmasq, чтобы он префикс раздавал. Опция --dhcp-range=lan,<начальный адрес>,ra-only,<префикс>,12h
потому что у хостеров обычно не-routed префиксы
зачем вообще нужны немаршрутизируемые ip6 префиксы? В любом случае всегда можно завести собственный маршрутизируемый префикс. Он ничего не стоит
и тут же
Никакого противоречия. Есть часто большая разница между "сделать сложно, зато красиво и правильно" и "сделать все максимально просто чтобы хоть как-нибудь работало". Том, кто хотел сделать все красиво и правильно, уже итак сделал, теперь надо помочь остальным.
По секрету, dnsmasq — не только dns, но ещё и dhcp сервер.
Стесняюсь спросить, а нахрена вам DHCP для L3 VPN и прокси-сервера?
Извините, но у вас все в кучу смешалось. Давайте по пунктам:
У всех свежих устройств сразу есть маршрутизируемые(!) ipv6 адреса. Не будем говорить откуда они берутся, но они есть. Но даже если в DNS хоста, к которому вы подключаетесь есть ipv6 адрес - вы никак туда не попадете по ipv6, т.к. нет шлюза и, соответственно, маршрута до этого ipv6 адреса.
Короче, не обращайте внимания на эти AAA. Сбои с этим не связаны. Сама по себе ipv6 маршрутизация у вас ниоткуда не возьмется. Надо получить маршрут и блок (обычно /64), от провайдера или туннельного брокера, раздать его устройствам, и тогда все будет работать по ipv6. Покуда этого нет - все шпарит по ipv4
Сбои с этим не связаны. Сама по себе ipv6 маршрутизация у вас ниоткуда не возьмется.
Скажите, а вы точно прочитали статью внимательно, или сразу же бросились комментировать? Речь про прокси с tun2socks, как пример. У них часто по умолчанию на TUN-интерфейс назначается в том числе захардкоденный IPv6-адрес fdfe:dcba:9876::1, IPv6-шлюз и прописывается маршрут через него. На ресурс вы действительно не попадете, если "на той стороне" на прокси-сервере нет IPv6-связности для выхода во внешний интернет. На этот случай должен быть fallback-механизм чтобы "все шпарило по IPv4", но этот механизм, как выяснилось, сломан у некоторых приложений. Речь в статье именно об этом (и о других похожих случаях)
Неожиданности IPv6, или почему тупят Instagram и WhatsApp через прокси и VPN