IPv6 - это катастрофа (но поправимая) - Хабр

8/14/23, 4:04 PM IPv6 — это катастрофа (но поправимая) / Хабр
IPv6 — это катастрофа (но поправимая)

Средний 12 мин 25K
Блог компании RUVDS.comСистемное администрирование*Сетевые технологии*IPv6*
Кейс Перевод
Автор оригинала: Mathew Duggan
В последнее время мы всё чаще слышим не самые приятные новости про IP-адреса. Компания
AWS объявила, что будет брать по $0,005/час за каждый адрес IPv4, тем самым присоединившись к
другим облачным провайдерам, сделавшим платным использование публичного адреса IPv4. GCP
просит с клиентов по $0,004, а Azure и Hetzner — по €0,001/ч. Очевидно, что эпоха, когда облачные
провайдеры расширялись, скупая дополнительное пространство IPv4, подходит к концу. Чем
дальше, тем ценнее становятся эти адреса, и тем менее целесообразно предоставлять их бесплатно.
Так что перспективы ясны — нам нужно переходить на IPv6. Впервые о необходимости перехода на
IPv6 я услышал, когда учился в колледже, а сейчас мне 36. Это я к тому, чтобы вы поняли, как давно
стали очевидны эти перспективы. До этого с IPv6 я не работал, на рынке практически отсутствовал
спрос на соответствующие навыки, и мне не доводилось трудиться в компаниях, где бы эта тема
кого-то интересовала. Поэтому и осваивать я её не стал, хотя зря, потому что она прекрасно
расширила бы мои навыки в сфере сетевых технологий.
+72 97 108
https://habr.com/ru/companies/ruvds/articles/753906/ 1/46
Но теперь настал очередной удачный момент, чтобы этим заняться, и я решил перевести свой блог
исключительно на IPv6. Он будет находиться за CDN для обработки трафика IPv4, но всё же пора
уже вступить в ряды крутых ребят. Однако в процессе я выяснил одну весьма неприятную вещь: в
IPv6 практически ничто не работает «из коробки». Основные зависимости тут же слетают, а
обходные решения оказываются не готовыми к продакшену. Процесс перевода команд на IPv6 будет
очень тернистым, преимущественно из-за того, что никто ещё с этим не сталкивался. Мы многие
годы откладывали освоение этой технологии, и теперь придётся за это платить.
Почему IPv6 стоит приложенных усилий?
Я не собираюсь подробно сравнивать IPv4 и IPv6. В сети есть множество прекрасных статей на эту
тему. Давайте просто вкратце посмотрим «Почему вообще есть резон переходить на IPv6».
Заголовок пакета IPv6
Пространство адресов (это очевидно).
Меньше полей заголовков (8 против 13 в v4).
Ускоренная обработка: отсутствие контрольной суммы, в связи с чем маршрутизаторам не

нужно выполнять перерасчёт для каждого пакета.
Ускоренная маршрутизация: больше общих и иерархических маршрутов. (Не знаете, что такое
«общий маршрут»? Поясню. Общий маршрут равнозначен совмещению нескольких IP,
благодаря чему вам уже не требуются все эти адреса, только их общее направление, основанное
на первой части адреса. То же самое касается маршрутов. Поскольку адреса IPv6 уникальны по
всему миру, вы можете использовать компактную и эффективную магистральную
маршрутизацию).
QoS (качество обслуживания): поля Traffic Class (класс трафика) и Flow Label (идентификатор
потока) упрощают предоставление качественного сервиса.
Автоматическая адресация. Позволяет хостам IPv6 в сети LAN подключаться без
маршрутизатора или DHCP-сервера.
Можно добавить в IPv6 набор протоколов IPsec с Authentication Header (заголовком
аутентификации) и Encapsulating Security Payload (безопасной инкапсуляцией полезной
нагрузки).
Ну и самое значительное: потому что адреса IPv6 свободны, в отличие от адресов IPv4.
Настройка сервера исключительно на IPv6
По факту процесс настройки оказался прост. Я подготовил ПК с Debian и выбрал «IPv6». Затем
возник первый сюрприз. Мой компьютер не получил адрес IPv6. Мне было выдано /64 адресов, а
именно 18,446,744,073,709,551,616. Приятно осознавать, что мой скромный сервер на ARM смог
масштабироваться для запуска всей сетевой инфраструктуры в каждой компании, где я работал, на
всех публичных адресах.
Такой подход кажется растратным, но если рассмотреть принцип работы IPv6, выяснится, что это не
так. Поскольку IPv6 намного менее «говорлив» в сравнении с IPv4, то даже когда у меня в сети было
10 000 хостов, это ничего не меняло. Как уже говорилось, есть смысл сохранить всё пространство
IPv6, даже если сначала это покажется безумно затратным. Так что просто не думайте, сколько
адресов отправляется на каждое устройство.
Важно: противьтесь желанию оптимизировать использование адресов. Общаясь с более

опытными системными администраторами, я понял, что это типичная ловушка, в которую
попадают очень многие. Мы все зачастую волновались, сколько пространства осталось в блоке
IPv4, и проводили немало времени за поиском решений этой проблемы. Теперь же она просто
исчезла. Префикс /64 является минимальным, какой вам нужно настроить в интерфейсе.
Попытка использовать префикс ещё меньше, например, /68 или /96, как известно по опыту
некоторых специалистов, может нарушить автоконфигурацию адресов без сохранения состояния. На
каждый сайт вам нужно подразумевать префикс /48. Именно такое значение выдаётся региональным
интернет-регистратором при выделении IPv6. Продумывая организацию сети, вам также нужно
определиться с ограничением по полубайту (nibble boundary). По сути, этот способ упрощает чтение
IPv6.
Предположим, у вас адрес 2402:9400:10::/48. Если вы захотите получить для каждой машины в
однотипной сети только /64, то поделите его так:
Подсеть Адрес подсети
0 2402:9400:10::/64
1 2402:9400:10:1::/64
2 2402:9400:10:2::/64
3 2402:9400:10:3::/64
4 2402:9400:10:4::/64
5 2402:9400:10:5::/64
Для /52 принцип тот же:
Подсеть Адрес подсети
0 2402:9400:10::/52
1 2402:9400:10:1000::/52
2 2402:9400:10:2000::/52
3 2402:9400:10:3000::/52
4 2402:9400:10:4000::/52
5 2402:9400:10:5000::/52
Вы по-прежнему можете сразу понять, какая перед вами подсеть.
Хорошо, свою машину я подготовил. Теперь попробуем настроить на ней рабочий сервер.
▍ Проблема 1 — не могу подключиться по SSH
Это была ожидаемая проблема. Протокол IPv6 не поддерживается ни моим домашним провайдером,
ни рабочим. Так что хорошо, что я настроил свою машину, но сделать теперь с ней я ничего не могу.
Ладно, пока что я подключил адрес IPv4, установил соединение по SSH и далее
настрою cloudflared для запуска туннеля. Возможно, этот сервис выполнит преобразование на
своей стороне.
Вот только Cloudflare работает иначе. Представьте себе моё удивление, когда в момент удаления
адреса IPv4 туннель закрылся. По умолчанию утилита cloudflared предполагает использование
IPv4, и вам необходимо добавить в служебный файл systemd следующее: --edge-ip-version 6 .
После этого туннель заработал, и подключиться по SSH мне удалось.
▍ Проблема 2 — не могу использовать GitHub
Хорошо, система налажена. Теперь пора заняться настройкой всего остального. Я запускаю скрипт
конфигурации сервера, и он тут же даёт сбой. Он пытается обратиться к инструкциям
установки hishtory, прекрасной программы отслеживания истории оболочки, которую я использую
для всех своих задач. Скрипт безуспешно пробует получить с GitHub файл её установки. «Но это
очень странно. Ведь GitHub должен поддерживать IPv6?»
А вот и нет. Конечно, очень плохо, что сервис, через который разработчики по всему миру
выпускают ПО, не поддерживает IPv6. Но ведь и у Microsoft возникли проблемы, и теперь эта
компания занимается только фальшивым ИИ, так что какая разница? В итоге я успешно использовал
TransIP GitHub Proxy. Теперь у меня есть доступ к GitHub. Но далее Python
выдал urllib.error.URLError: <urlopen error [Errno 101] Network is
unreachable> . Ладно, сдаюсь. Предполагаю, что версия Python 3 в Debian не дружит с IPv6, но
сейчас я не в настроении с этим разбираться.
▍ Проблема 3 — не могу настроить Datadog
Займёмся чем-то попроще. Я определённо могу настроить Datadog, чтобы следить за своей
машиной. Мне не нужно множество метрик, лишь несколько исторических данных о загрузке.
Перехожу в Datadog, авторизуюсь и запускаю процесс… Сразу же сбой. Простая настройка
подразумевает выполнение curl -L https://s3.amazonaws.com/dd-
agent/scripts/install_script_agent7.sh . Но ведь S3 поддерживает IPv6, тогда какого
чёрта?
curl -v https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh
* Trying [64:ff9b::34d9:8430]:443...
* Trying 52.216.133.245:443...
* Immediate connect fail for 52.216.133.245: Network is unreachable
* Trying 54.231.138.48:443...
* Trying 52.217.96.222:443...
* Trying 52.216.152.62:443...
* Trying 54.231.229.16:443...
* Trying 52.216.210.200:443...
* Trying 52.217.89.94:443...
* Trying 52.216.205.173:443...
123456789101112131415161718
Проблема не в S3 или машине, потому что я вполне могу подключиться к тестовому бакету S3,
который предоставляет AWS.
curl -v http://s3.dualstack.us-west-2.amazonaws.com/
* Trying [2600:1fa0:40bf:a809:345c:d3f8::]:80...
* Connected to s3.dualstack.us-west-2.amazonaws.com (2600:1fa0:40bf:a809:345c:d3f8::)
> GET / HTTP/1.1
> Host: s3.dualstack.us-west-2.amazonaws.com
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 307 Temporary Redirect
< x-amz-id-2: r1WAG/NYpaggrPl3Oja4SG1CrcBZ+1RIpYKivAiIhiICtfwiItTgLfm6McPXXJpKWeM848Y
< x-amz-request-id: BPCVA8T6SZMTB3EF
< Date: Tue, 01 Aug 2023 10:31:27 GMT
< Location: https://aws.amazon.com/s3/
< Server: AmazonS3
< Content-Length: 0
<
* Connection #0 to host s3.dualstack.us-west-2.amazonaws.com left intact
1234567891011121314151617
Хорошо. Я проделаю всё вручную через apt.

0% [Connecting to apt.datadoghq.com (18.66.192.22)]
Да ёпрст! Ладно, Datadog исключается. В этот момент я понял, что эксперимент с использованием
только IPv6 не сработает. Почти ничто не работает напрямую без посредника или всяческих
ухищрений. Попробую по максимуму придерживаться IPv6, но использовать только его пока точно
не вариант.
NAT64
Для доступа к ресурсам IPv4 через IPv6 вам нужно пройти через сервис NAT64. Я использовал этот.
Тут же все мои проблемы исчезли. Я немного переживаю, насколько можно доверять процессы
взаимодействия с критическими интернет-ресурсами сервису, по сути являющемуся хобби-
проектом. Но раз уж, по всей видимости, ни один из восходящих сервисов не утруждается
налаживанием работы IPv6, то выбора у меня особо не остаётся.
Я удивлён, насколько мало доступно альтернатив. Вот весь список провайдеров, какой мне удалось
собрать:
Большинства из них сейчас уже нет. Связь Dresel не работает, Trex в ходе тестирования вызывал
проблемы, August Internet закрылся, большинство тестовых устройств Go6lab отключены, Tuxis
сработал, но их сервис был запущен в 2019 и, похоже, с тех пор не дорабатывался. По сути, Kasper
Dupont является единственным, реально заинтересованным в продвижении IPv6. Спасибо тебе,
Kasper.
Да, по факту развитие этого сегмента всемирной сети держится на плечах всего одного человека.
▍ Kasper Dupont
Мне стало интересно познакомиться с этим энтузиастом, и я написал ему письмо с несколькими
вопросами. Вот часть нашей переписки:
Я: Лично мне сервис Public NAT64 показался очень эффективным инструментом перехода, но я
хотел бы побольше узнать, почему вы этим занимаетесь.
Каспер: я делаю это в первую очередь ради продвижения IPv6. В течение нескольких лет у меня
была возможность пользоваться дома нативной сетью исключительно на IPv6, используя
DNS64+NAT64, и мне этот опыт очень понравился. В результате я просто захотел дать и другим
людям возможность его испытать.
Когда я поднял первый шлюз NAT64, это стало просто подтверждением работоспособности
расширения NAT64, которое я хотел распространять. Сервис NAT64 стал популярен, а вот
расширение не особо.
Несколько месяцев назад я, наконец, наладил нативный IPv6 у себя в новом доме, поэтому
сейчас могу использовать собственный сервис так, как предполагается его использование
целевыми потребителями.
Я: Похоже, ваш сервис является одним из немногих оставшихся в бесплатном доступе, и мне бы
хотелось понять, что подталкивает вас продолжать этим заниматься, сколько стоит его
обслуживание, да и любые мысли, какими вы бы сами хотели по этому поводу поделиться.
Каспер: Под мои личные продукты у меня запущено 7 виртуальных машин, подключённых к
разным хостингам. Некоторые из них я арендую у Hetzner по 4,51 евро в месяц.
Другие VM обходятся чуть дороже, но ненамного.
Из всех машин 4 используются для сервиса NAT64, а остальные для других сервисов, связанных
с переходом на IPv6. Например, на отдельной VM у меня работает этот сервис.
Надеюсь, что в итоге договорюсь с промежуточными провайдерами и смогу расширить

возможности сервиса, а также сделать его прибыльным. Это бы позволило мне посвятить себя
работе над IPv6 полностью, а не частично, как это есть сейчас. Идеальным исходом будет, если
провайдеры, работающие только с протоколом IPv4, будут оплачивать расходы в рамках своих
платежей за использование пропускной способности.
Я: Было бы здорово, если бы вы рассказали о каких-нибудь технических деталях своего проекта.
Каспер: Сразу видно — свой человек :-)
Я могу углубиться в детали очень сильно.
Думаю, что мой сервис отделяет от других то, что каждый из моих серверов DNS64
автоматически обновляется префиксами NAT64 на основе проверки состояния всех шлюзов. Это
означает, что выход из строя любого отдельного шлюза NAT64 окажется для потребителей
практически незаметен. Кроме того, это упрощает обслуживание. Думаю, благодаря этому, мой
сервис предоставляет один из высочайших уровней доступности среди всех публичных
сервисов NAT64.
Весь код NAT64 разработан мной, и на данный момент он выполняется как демон в
пространстве пользователя Linux. Правда сейчас я подумываю о переносе наиболее важной для
производительности части в модуль ядра.
Сайт оригинала статьи
Хорошо, всё основное я наладил. Для передачи контейнеров Docker через IPv6 вам потребуется
добавить в начало имени образа следующее: registry.ipv6.docker.com/library/ .
Например, image: mysql:8.0 станет image:
registry.ipv6.docker.com/library/mysql:8.0 .
Docker предупреждает, что данная конфигурация не готова к использованию в продакшене. Я не

уверен, что это конкретно значит для Docker. Возможно, если всё наладить, то вы просто сможете
скачивать образы как обычно?
Разобравшись с этим, я настроил сайт как запись DNS AAAA и позволил Cloudflare выступить в
качестве посредника, то есть этот ресурс сможет обрабатывать оповещения IPv6 и перенаправлять
трафик ко мне. По сравнению с прежней конфигурацией я изменил одну вещь. Раньше я
использовал веб-сервер Caddy, но поскольку теперь бо́ льшая часть моего трафика поступает через
Cloudflare, я переключился на Nginx. Зная, что весь трафик поступает от Cloudflare, вы можете ради
удобства сменить режим работы SSL.
Теперь у меня в Nginx загружен сертификат Origin из Cloudflare с настроенной функциональностью

Authenticated Origin Pulls, поэтому я уверен, что весь трафик поступает именно через Cloudflare.
Этот сертификат выдаётся на 15 лет, так что я могу уверенно внедрить его в систему управления
учётными цифровыми идентификационными данными и забыть. Для интересующихся этой темой
есть хорошее руководство.
Отлично. Сайт налажен и работает.
Нерешённые проблемы
Мои контейнеры по-прежнему не могут взаимодействовать с ресурсами IPv4 несмотря на то,

что находятся в сети IPv6 с мостом IPv6. Разрешение имён DNS64 работает, и я также добавил в
Docker fixed-cidr-v6 . Я могу прекрасно взаимодействовать с ресурсами IPv6, но
преобразование NAT64 не функционирует. Буду с этим разбираться.
Пришлось добавить NAT с ip6tables.
Проблемы с SMTP-сервером. Я не смог найти коммерческий SMTP-сервис, имеющий запись
AAAA. Я опробовал Mailgun, SES и несколько более мелких — ни один не подошёл. Даже
Fastmail не сгодился. Если вам известен хороший вариант, будьте добры, напишите мне сюда.
Почему бы не продолжать использовать IPv4?
Давайте на минуту забудем, что у нас кончаются адреса. Если бы мы начали внедрять IPv6 раньше,
то построение инфраструктуры происходило бы совсем иначе. Компании зачастую используют
такие технологии, как балансировщики нагрузки и туннели, не потому что фактически нуждаются в
них, а потому что им требуется некий способ разделить закрытые IP-диапазоны и открытый IP-
адрес, который они могут внести в запись DNS А.
Если разбить балансировщик нагрузки на составляющие, то он выполняет две задачи: распределяет

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

следующие:
1. Round-robin. Круговая обработка запросов на подключение.
2. Weighted Round-robin. Взвешенная круговая обработка, в результате которой сервера получают

больше или меньше нагрузки.
3. Least-Connection. При получении новых запросов их распределение происходит по серверам с
наименьшим числом подключений.
4. Weighted Least-Connection. То же самое, но можно отдавать приоритет определённым машинам.
Как видите, здесь нет ничего, что требовало бы или получало преимущество от использования
закрытого IP-адреса вместо публичного. Настройка хостов для получения трафика только от одного
источника (балансировщика нагрузки) производится просто и относительно дёшево в
вычислительном смысле. Многие схемы инфраструктуры, с которыми мы оказались вынуждены
работать, например, VPC, шлюзы NAT, публичные и закрытые подсети — без всех них можно было
либо обойтись полностью, либо опираться на эти решения в меньшей степени.
Ещё одна ирония заключается в том, что практика формирования белых списков IP-адресов, которая
сейчас является неактуальной, поскольку мы все используем адреса, принадлежащие облачным
провайдерам, в этом случае оказалась бы кстати. С появлением спроса компаниям стало бы проще
приобретать для себя адреса с префиксом /44, и люди бы начали чаще обращаться за покупкой блока
IP-адресов в Американский реестр номеров интернета (ARIN), Координационный центр
распределения ресурсов сети интернет в Европейском регионе (RIPE) или Азиатско-Тихоокеанский
сетевой информационный центр (APNIC).
Вам бы никогда не пришлось думать о том «Купит ли Google дополнительные IP-адреса» или «Мне
нужно мониторить страницу поддержки GitHub, чтобы убедиться, что они не добавят их позднее». У
вас бы был один блок, который компания бы использовала для всего бизнеса до конца его
существования. Системам контейнеров не потребовалось бы присваивать внутренние IP-адреса
каждому хосту, достаточно было бы выделять для них сегменты публичных IP, а также при
необходимости делать оповещения через стандартные публичные DNS.
Я не утверждаю, что закрытые сети не нужны. Мой посыл заключается в том, что многие виды
используемых нами сетевых структур основаны не на необходимости, а на навязанном дизайне.
Подозреваю, что в ином случае мы бы начали разрабатывать приложения с пониманием того, что
они работают через открытый интернет, а не стали бы опираться полностью на безопасность
закрытых VPC. Учитывая, как работают эксплойты, это наверняка пошло бы на пользу дизайну и
безопасности в целом.
Так что, даже если стоимость и доступность не являются для вас проблемой, то предоставление
вашей организации более широкого права собственности и контроля над функционированием сети
принесло бы ощутимую ценность.
Улучшится ли ситуация?
Так что пока всё печально. Вы либо платите облачным провайдерам больше денег, либо получаете
полурабочий интернет. Надеюсь, что те, кто не хочет платить больше, продвинут идею
использования IPv6. Считаю, что нам также должно быть стыдно за то, что потребовалось так много
времени для осознания всего этого. Все проблемы можно было решать постепенно, но теперь этот
процесс будет доводить людей до безумия, пока команды, управляющие такими ресурсами, не
внесут необходимые изменения.
Надеюсь, что в конечном итоге ситуация всё же улучшится. Думаю, по меньшей мере, это должно
открыть новые возможности для небольших компаний, стремящихся занять для себя IP-диапазон,
которым они будут пользоваться неограниченное время. К тому же, наверняка с распространением
IPv6 упростится и его использование. Но должен сказать, что сейчас эта технология находится в
поразительно плачевном состоянии.
Если вы являетесь небольшой компанией, которая не желает платить лишние налоги на IP, уделите
время на решение множества проблем, с которыми вам предстоит столкнуться.
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх 🕹️
Теги: ruvds_переводipv6ipv4сетевые технологииоблачные технологииdnsnat64
Хабы: Блог компании RUVDS.comСистемное администрированиеСетевые технологииIPv6
Редакторский дайджест
Присылаем лучшие статьи раз в месяц
Электропочта
RUVDS.com
VDS/VPS-хостинг. Скидка 15% по коду HABR15
Telegram ВКонтакте Twitter
291 205.4
Карма Рейтинг
Дмитрий Брайт @Bright_Translate

Переводчик
Комментарии 108
Skykharkov
вчера в 13:47
Если коротко пересказать статью - то что IPv6 представляли как "серебряную пулю" получилось,
пока что, как пуля совсем из другого мягкого материала... А еще миллионы (если не миллиарды)
сетевых железяк, которые никак IPv6 не поддерживают, и никто их обновлять не будет, за дурные
деньги и так далее... В идеале, если с нуля делать, то конечно оно супер будет. Но долго еще
сисадмины будут седеть в поисках стабильных решений скрещивания того что есть с IPv6. А так
идея, разумеется великолепная... Я про саму концепцию IPv6.
+23 Ответить
DreamingKitten
18 часов назад
то что IPv6 представляли как "серебряную пулю"
Кто представлял?
А еще миллионы (если не миллиарды) сетевых железяк, которые никак IPv6 не

поддерживают
Все маршрутизаторы уровня чуть выше домашних уже лет как 15-20 умеют в ipv6.
Но долго еще сисадмины будут седеть в поисках стабильных решений скрещивания того
что есть с IPv6.
Дуалстэк прекрасно работает годами. Отказываться от него пока рано.
+9 Ответить
iskatel
"Все маршрутизаторы уровня чуть выше домашних уже лет как 15-20 умеют в ipv6."
как человек с более чем 20-летним опытом и присутствовавший на семинарах RIPE в 2002 и
2003г., где тогда активно обсуждался и продвигался "новый классный протокол", могу сказать :
массовой поддержки V6 20 лет назад не было, и в последующие годы тоже не было, тогда она
была фрагментарной.
Даже в серьёзном сетевом железе полная (те. не "ой, смотрите, вот у нас что-то запустилось и
пакетиуи бегают!") поддержка появилась позднее.
Ну и массовая поддержка V6 в огромном кол-ве сетевых сервисов и софте - это уже 2010е гг.,
где-то в районе 2015го, +- пара лет.
Причём 100% поддержки нет по сей день.
vikarti
Все маршрутизаторы уровня чуть выше домашних уже лет как 15-20 умеют в ipv6.
IPv6 NAT у Mikrotik появился в RouterOS7 только (речь про NPTv6 конечно же). Зачем нужен
NAT в IPv6? А потому что какой еще нормальный вариант с мультихомингом если нет
возможности BGP поднимать с провайдерами?
Про /48 на сайт — ну вы это провайдерам объясните. Которых в рекомендации RIPE тыкаешь
что хотя бы /56 надо но им пофиг, хватит клиенту и /64?
Это если IPv6 вообще — есть.
С DNS — если у провайдера есть возможность задавать rDNS для IPv4-адресов, совсем не
факт что будет аналогичная возможность для IPv6 хоть в каком то виде.
Вот и получается что проще — туннель до he.net но тут скорость падает.
+2 Ответить
dreamer2
вчера в 13:49
1. нам не хватает адресов - давайте придумаем протокол в котором выбросим по /64 на каждое
устройство, всё равно никто не придумал что с ними делать...
2. nat навязан устаревшим старым протоколом - давайте вообще избавимся от закрытых сетей,
ну а кому надо пусть сам придумывает, что будет фильтровать на границе.
Отличный и продуманный дизайн - впрочем все уже оценили по внедрению.
Nurked
вчера в 14:22
По поводу первого - категорически несогласен. Как показывает практика, у современных

инженеров очень сильно плохо всё с масштабами мышления. Идиотизмы, типа "тысяча
адресов на человека будет достаточно" или "640 килобайт хватит всем" или "8 мегов рама -
более чем", даже тот же самый UnixTime это полный бред из этой же категории.
Пусть будет /64 уж если что, будем по блоку на планету выдавать в будущем.
По поводу второго - возражений нет.
FSA
вчера в 14:35
1. /64 вполне обосновывается тем, что имея 64 бита можно вписать в адрес любой
существующий MAC адрес и гарантированно получить уникальный адрес ни с кем не
пересекающийся. В контексте серверов, это позволит сократить размер адреса благодаря
тому что вторая часть будет состоять из нулей. А если ещё учесть сеть /48, которую вы
можете легко получить, то можно получить очень короткий адрес.
2. NAT - это костыль, который был придуман для того, чтобы в сеть могли выйти те узлы,
которые его не имели. В IPv6 тоже есть NAT и если вы желаете, то можете его
использовать. К тому же NAT64 практически делает незаметным отсутствие IPv4 на
машине, но за редким исключением, когда IPv4 адреса жёстко вшиты в программу. Но и
для этого найдётся свой костыль в виде NAT46, который нужно установить на само
устройство или ваш маршрутизатор (который, кстати говоря, уже занимается NAT44). И
научитесь уже использовать файервол для защиты, а не NAT. Файервол как раз для этой
задачи предназначен.
Основная проблема внедрения IPv6 - это нежелание людей разбираться в новом

протоколе. Даже если провайдер вам его предоставляет, можно столкнуться с ситуацией,
когда IPv6 перестаёт работать. Домашние провайдеры (например, Ростелеком)
отказываются чинить баги ссылаясь на то, что они этот протокол не поддерживают, но по
факту предоставляют, т.к. это позволяет снизить нагрузку на перегруженный провайдерский
NAT. Все эти проблемы не вина протокола, но при этом, конечно, отпугивает новичков.
Уже сейчас можно перевести сеть на IPv6 и спокойно жить. А чтобы получить доступ к
ресурсам IPv4 использовать уже знакомый костыль -NAT. Только в отличие от
провайдерского NAT для IPv4, нагрузка на этот NAT будет падать по мере внедрения IPv6
и, в теории, вообще необходимость в нём отпадёт.
lexore
22 часа назад
И научитесь уже использовать файервол для защиты, а не NAT. Файервол как раз для
этой задачи предназначен.
Вы это хотите сказать всем пользователям интернета?
LAZst
Это хочется сказать тем кто с пеной у рта доказывает что без NATа нет защиты...
А пользователям интернета пофигу чеге какой протокол отобразится их любимый

вконтактик, хоть голубями пакеты пересылайте ))))))
+7 Ответить
DreamingKitten
Да.
Потому что, если вы вдруг забыли, само слово "Интернет" обозначает связность каждый
сети с каждой. И эту связность NAT ломает.
+8 Ответить
Megakazbek
"Связность каждый сети с каждой" - это бесполезное свойство, которое оказалось

невостребованным и сейчас скорее представляет угрозу безопасности, чем то, к чему
нужно стремиться. Нет смысла об этом даже вспоминать в мире, в котором интернет
обозначает, что ты с телефона можешь заказать пиццу.
+5 Ответить
vikarti
Это очень полезное свойство. Хотя бы тем, что дает возможность убрать CGNAT который
ресурсы сейчас жрет у многих провайдеров.
Ну и — мессенджерам и им подобным как бы совсем не хорошо через сервер
ретранслироватся (что еще и сервер грузит) ну или надо не всегда рабочие схемы обхода
NAT'а
0 Ответить
DreamingKitten
"Связность каждый сети с каждой" - это бесполезное свойство,
Да ладно?
Если вы интернетом пользуетесь только для заказа пиццы, то не надо судить о других по
себе.
Раз в пол-года на Хабре появляется очередная статья с нытьём о том как у IPv6 всё плохо
и как он никому не нужен. Под каждой такой статьёй каждый раз разгорается один и тот же
срач с одними и теми же аргументами.
Вот чтобы не повторяться, по поводу невостребованности
https://habr.com/ru/articles/711444/comments/#comment_25130512
+4 Ответить
encyclopedist
1 час назад
"Связность каждый сети с каждой" - это бесполезное свойство, которое оказалось

невостребованным
Ага-ага, скажите это всем разработчикам, которым приходится изобретать NAT hole
punching на свой лад, как только понадобится сделать что-то peer-to-peer.
+3 Ответить
Antra
21 час назад
Конечно же, NAT - это не средство безопасности. Но если из сотни серверов мне нужно
сделать доступными из Интернета штук 5, я вовсе не хочу, чтобы любой мой внутренний IP
(IPv6) маршрутизировался и был доступен извне, и условная MongoDB стала публично
доступной из-за малюсенькой ошибки в правиле на фаерволе.
Даже имея сеть класса C мне в голову не придет каждому из сотни серверов выдать по
публичному IP. Я либо кусочек сети с публичными адресами замаршрутизирую в DMZ, либо
даже DMZ серверы сделаю доступными извне через NAT. И уж точно серверы, которые не
должны быть доступными из Интернета, буду выходить в Инет через NAT, но ни в коем случае
не быть на публичных маршрутизируемых адресах. А-ля NAT66 (хотя мне казалось,что он в
очень незрелом состоянии).
Для меня идеально иметь внутри сети IPv6 и не думать об адресах, а "снаружи" - IPv4. И
пусть фаервол имеет не только политику с правилами доступа, в которой можно случайно
открыть огромную сеть, но и делает Static NAT из IPv4 в IPv6 только для "избранных".
Клиенты мобильных операторов (и ряд других кейсов), разумеется, отдельная песня.
VADemon
Если у вас во внутреннем контуре IPv6, то какой? И почему не site-local?
0 Ответить
Antra
Я отвечал на "NAT - это костыль", пытаясь показать, что даже при использовании IPv6
всем серверам и устройствам выдавать публично маршрутизируемые адреса - не лучшая
идея. NAT все равно не повредит, с ним безопаснее будет.
Если же использовать site-local - тем более без NAT не обойтись. И точно так же можно
столкнуться с тем, что "купили компанию, надо объединять сети, а там совпадает
адресное пространство".
Нет уж. Я бы регистрировал свой IPv6 блок, но использовал его внутри, в Интеренет не
маршрутизировал, а наружу выпускал бы через NAT.
+8 Ответить
veryboringman
Нужно только помнить, что NAT - это не firewall. И он в любом случае нужен.
Высшее достижение NAT-строения - Carrier grade NAT у сотовиков. Врагу такого не

пожелаешь.
+1 Ответить
Antra
Безусловно. Я вообще за эшелонированную защиту.
Интернет-фаервол - DMZ - Другой фаервол - бэкбон - ЦОД фаервол - серверные сегменты
Причем на Интернет фаерволе даже маршрутов в сторону "корпоративной сети" нет. Он

только про DMZ сети знает.
Где бы и кто бы ни ошибся - внутренний сервер из ЦОД не окажется внезапно exposed.
+2 Ответить
veryboringman
Не совсем только понятно, почему в этой схеме не может быть ipv6?
NAT в ipv6 тоже есть, просто он гораздо проще реализуется, чем в ipv4 и менее глюкав из-
за этого.
0 Ответить
Antra
Конечно же может. Но не для того, чтобы избавиться от NAT.
И вы о каком NAT говорите? IPv6-to-IPv6 Network Prefix Translation (NPTv6) или NAT66?
+2 Ответить
veryboringman
В том числе и для избавления от NAT.
Я говорю про NPTv6 - потому что исчезает кривая схема с транслированием портов. Вот
прямо сейчас ее и применяю.
+1 Ответить
nidalee
Я сам не сисадмин, но вроде как все файерволлы из коробки блокируют все, что не
разрешено? Тот же ufw.
Если вы зачем-то разрешили in на порт mongodb, то это ССЗБ.
Не поставили файерволл — ну, в общем-то, тоже.
А у домохозяек он как бы из коробки. Если только знакомый-вредитель им не поставил
говносборочку с вырезанным "ненужным" брандмауэром windows...
+5 Ответить
powerman
1 час назад
ufw - локальный на сервере. Там порт монги открыть придётся, иначе к ней никто из
локалки не сможет подключиться. Вопрос в том, чтобы теперь на этот открытый порт никто
из инета не пришёл - а это уже должно делаться не в ufw сервера монги, а на роутере. И
настройка файрвола этого роутера с введением IPv6 заметно усложняется, т.е. растёт и
вероятность ошибок. В результате в среднем защита в сетях IPv6 получается ниже. Не
потому, что её невозможно сделать (почти) идентичной, а потому, что людям свойственно
совершать ошибки и чем больше возможностей для ошибок система предоставляет тем
больше ошибок будет совершаться - а IPv6 возможностей для ошибок предоставляет
заметно больше.
+1 Ответить
NAI
48 минут назад
"Просто поверьте, у нас не всё так однозначно" (С) мем
Мой опыт и то с чем столкнулся. Провайдер выдает IPv6 - все ок. Микротом пробросилось,
все счастливо работает. Местами даже блокировки обходятся.
Проблема 1 - статичный IPv6. С IPv4 понятно, вот мой DHCP-сервер, вот создал запись,
вот я знаю что 88.10 - это телевизор. IPv6 - SLAAC. Т.е. мне надо вкорячить DHCPv6
между мной и провом. И тут надо погружаться и становиться админом чтобы эт все
настроить. Не погружался, но кажется микрот до сих пор так не умеет (если умеет нужна
ссыль).
Проблема 1.5 - вы же в курсе что win10 (на других не проверял) для того чтобы
"обезопасить" и "анонимизировать", каждый раз запрашивает temporary IPv6 адреса?
Звучит как костыль, выглядит как костыль, ведет себя как костыль, значит перед нами
костыль. (да, отключаемый, но збс - надеяться что ты выключишь ПК быстрее чем кто-
нибудь сумеет воспользоваться какой-нибудь уязвимостью)
Проблема 2 - решение которой лично я не нашел. Windows firewall по дефолту блокирует

не все. По этому если представить ситуацию что FW на роутере по умолчанию разрешает
какие-то входящие, то можно получить сканером портов. А теперь думаете домохозяйки и
прочие геймеры будут запариваться с FW на маршрутизаторе, FW на ПК? Сидеть и думать
че-куда там пробросить надо? Да все жмакнут Allow, лишь бы запустилось и все.
Проблема 2.1 - Если проблему 1 маршрутизатор решить не может, то и публиковать

внутренние ресурсы наружу становится невозможно. Т.к. надо будет или открывать доступ
ко всем или после ребута можно получить смену IPv6 и тыкву вместо сервиса.
Проблема 3 (надуманная) - правила FW IPv4 я могу протестировать хоть с мобилки. А вот

IPv6 нифига, кроме моего провайдера никто не дает. Как итог - настроил, работает, а вот
чего открыто, как FW работает, не протестить. Надо идти в AWS (ну или любое другое
облако) и брать инстанс с IPv6. Так каждый раз. =\
+1 Ответить
ValdikSS
И уж точно серверы, которые не должны быть доступными из Интернета, буду

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

обычным firewall с блокировкой входящих соединений?
0 Ответить
Antra
В человеческом факторе.
Что нужно, чтобы открыть доступ к серверу на публичном адресе? Чуток поменять
правила. Они же не статичные. Не тот хост добавил в разрешенные.. Хотел дать доступ
только из ЛВС, а сдуру открыл из Интернета... Не то drop правило удалил или просто
перетащил выше этого блокирующего... Сетку с разрешениями указал /28 вместо /29...
Когда в политике сотни правил такое легко может случиться. Я уж молчу про "случайную
ошибку маршрутизации в обход фаервола", особенно при наличии всяких резервных
каналов.
А вот если действительно хочешь опубликовать ресурс с приватного адреса в Инете, надо
дополнительно к фаервольским правилам еще явным образом Static NAT сделать. Причем
выбрать не задействованный под другие серверы. Это уже напрячься надо, не просто
"рука дрогнула".
Повторюсь, NAT сам по себе - не средство безопасности. Как и маршруты, VLAN и многое
другое. Можно обойтись и без него. Но он дополнительно уменьшает риски в случае
человеческой ошибки. С ним нужно больше ошибок совершить для бадабумса (хотя это
отнюдь не значит, что с NAT вы в полной безопасности).
0 Ответить
Heggi
Вот у меня есть конкретный пример, когда нужен NAT для ipv6.
Имею 2 4to6 туннеля, один в рф, другой не в рф. Хочу, чтобы сайты из рф ходили через
туннель в рф, остальные через второй.
Без NAT имею, что каждый девайс в сети имеет по два IPv6 адреса и с какого source IP пойдет
запрос - вообще не угадать. И через какой туннель уйдет запрос - тоже не угадать (а туннели
вредные, если пакет идет не с их source IP, то пакет дропается).
С NAT это решилось бы легко и просто маршрутами на роутере. Как решить это без NAT -
идей никаких.
upd: для конторы со своей AS все решается с помощью BGP. Для дома BGP не вариант.
0 Ответить
Sap_ru
"и с какого source IP пойдет запрос - вообще не угадать", но это вы просто не умеете его
готовить. В системе тоже есть маршрутизация для source interface. В Linux через route
tables.
+2 Ответить
Heggi
Но настраивать маршрутизацию на каждом телефоне-телевизоре тоже не дело. Такое

должно на роутере настраиваться.
0 Ответить
ValdikSS
24 минуты назад
Оно и настраивается, через сообщение маршрутов клиенту в Route Advertisement.
0 Ответить
Heggi
Осталось бытовые роутеры научить этой штуке. Ну и сами девайсы научить принимать.
0 Ответить
vikarti
Есть. Но вот только как быть в ситуациях когда устройство есть. Даже может быть с Linux.
Но вот консоли нет (кроме разве что отладочного UART внутри корпуса). Подразумевается
автонастройка приложением умного дома. Не опенсорсным конечно же.
0 Ответить
FSA
Вот у меня есть конкретный пример, когда нужен NAT для ipv6.
Да кто ж вам NAT запрещает то? Я бы, пожалуй, вашу задачу тоже бы с ходу решил через
NAT. На устройствах пользователей основной IPv6 от провайдера. А на шлюзе
маршрутизация нужных адресов в нужный туннель, на конце которого NAT с его
собственной адресацией. При чём транслировать можно адреса 1:1, а значит даже
состояние не нужно запоминать для соединений.
NAT плох там, где его рассматривают как средство обеспечения защиты сети, хотя он им не
является. К тому же, повсеместное применение его приводит к неявному отказу от главного
принципа Internet: сквозной прозрачности на сетевом уровне [RFC 2775], когда любой хост А
может послать пакет IP любому хосту Б (где А может быть равно Б). В вашем варианте,
кстати, сквозная прозрачность нарушена, так что почему бы в этом случае не использовать
NAT как средство обхода проблемы.
+1 Ответить
vikarti
Запрещают те кто активно устроили пропаганду, что NAT в любой форме на IPv6 не нужен.
И поддержка в софте — не нужна. Из-за чего та поддержка совсем не сразу появляется.
То, что есть товарищи у которых NAT это замена firewall — это отдельная проблема.
+1 Ответить
Pochemuk
Вы в самом деле думаете, что все MAC-адреса уникальны?
1. У меня как-то был в локалке компьютер, у которого MAC-адрес совпадал с MAC-адресом

сетевого принтера. Было весело.
2. Как-то поставили нам несколько терминалов для бесконтактных пропусков. У двух из них
были одинаковые MAC-адреса. Убил 5 часов на поиск плавающей нестабильности их
функционирования. Думал, что я сошел с ума. Они как бы работали, но не всегда.
0 Ответить
buldo
Как админ локалхоста могу сказать , что "нежелание людей разбираться" вполне объяснимо.
Разрыв сложности между привычным ipv4, который просто как два пальца и его понимают
даже не специалисты и ipv6 - просто огромен. Новые концепции, куча режимов, магия.
Сколько раз пытался осилить ipv6, так и не смог.
0 Ответить
ValdikSS
Базовые концепции маршрутизации ровно такие же. Если вы считаете IPv4 «простым как
два пальца», то вы, вероятно, мыслите в концепциях типичной конфигурации вашего
роутера не дальше вашей квартиры.
0 Ответить
GennPen
На сколько помнится, по стандарту /64 дается на подсеть. А там уже либо DHCPv6 с выдачей
рандомных/последовательных адресов как в DHCPv4, либо SLAAC.
IPv6 это отличная замена, и уже почти полностью рабочая. Однажды я что-то тестировал на
компьютере, отключил IPv4 и забыл про это, а потом несколько дней сидел не замечая. Только
после того как заметил что некоторые редкие сайты перестали открываться вспомнил.
+1 Ответить
FSA
некоторые редкие сайты перестали открываться
Ну не такие уж и редкие. В России большинство сайтов не имеет IPv6. Да что там, далеко
ходить, даже Хабр не имеет IPv6 адреса! Но если у вас был доступен DNS64+NAT64, то вы
вполне могли не заметить отсутствие IPv4 на вашей машине. Знаю только одно приложение,
которое не умеет в IPv6 сеть - это Steam. Видимо у него внутри вшиты IP адреса серверов. Но
и это лечится путём запуска NAT46 непосредственно на вашей машине.
А вообще слышал, что Европейские провайдеры уже строят свои сети только на основе IPv6.
Но ведь клиенты будут недовольны, что у них доступа нет? А вот и нет. Используется
технология MAP-T. При этом сеть провайдера полностью построена на IPv6. Весь пул адресов
они выделяют для NAT64. Один IPv4 адрес они делят между несколькими абонентами.
Каждому выделяется определённое количество портов. При чём связь используется
статичная, т.е. не нужно сохранять даже состояния соединений. На клиентской же стороне
маршрутизатор по классике даёт какую-то серую сеть, типа 192.168.1.0/24 или аналогичную. А
все соединения с серверами IPv4 направляются не на обычный NAT, а NAT46, который
использует только строго выделенный диапазон портов, который согласован с набором на
NAT64 у провайдера. Т.е. схема получается почти аналогичная тому, что есть сейчас с IPv4,
только трафик между маршрутизатором клиента и NAT провайдера теперь идёт по IPv6. К
тому же теперь провайдерскому NAT не нужно следить за состоянием соединений, т.е. он
становится менее требователен к железу. Нагрузка на этот NAT будет постепенно снижаться
ввиду того, что больше ресурсов будет доступно по IPv6 напрямую.
+6 Ответить
VADemon
Про провайдеров верно, туннель на IPv6.
Мне интересно, что творится, когда размер IPv4 пакета проходит около MTU сети? IPv4 MTU
искусственно занижен или пакеты фрагментируются на стороне провайдера?
0 Ответить
DreamingKitten
Да что там, далеко ходить, даже Хабр не имеет IPv6 адреса!
У hsto.org есть.
Но это, судя по всему, какой-то побочный эффект а не сознательное внедрение.
0 Ответить
ultraElephant
Проблема открытости/закрытости внутренней сети высосана из пальца. Какая разница будет ли

на пограничном устройстве nat или `ip deny any any` на вход?
+3 Ответить
M_AJ
давайте вообще избавимся от закрытых сетей, ну а кому надо пусть сам придумывает, что
будет фильтровать на границе.
Вот каждый раз меня это тригеррит. NAT -- это не замена фаерволу.
0 Ответить
dreamer2
1 час назад
а с чего столько людей стриггерилось на нат если речь про четко описанный в статье посыл "я
не утверждаю что закрытые сети не нужны совсем, но это навязанный дизайн и на самом
деле они вам не нужны" ?
при этом нат это конечно не фильтр, но средство изоляции сетей, что не однократно тут же в
комментариях подтверждается
0 Ответить
M_AJ
1 час назад
при этом нат это конечно не фильтр, но средство изоляции сетей
Потому что NAT это не средство изоляции сетей. Для изоляции как раз и придуман фаервол,
и нормальный дизайн сети как раз предусматривает настроенный нормально закрытый
фаерволл, а NAT, как следует из его названия, это механизм трансляции адресов.
0 Ответить
dreamer2
можно сколько угодно триггериться от того что кто-то забивает шурупы молотком, но это не
изменит существующей реальности
точно так же как и те кто признают, что нат мешает связности и придумывают средства
пробивки нат почему-то думают, что фаерволы у юзер роутеров в дефолтных конфигах
разрешат подключаться их в6<->-в6 приложухам без проблем
судя по темпам внедрения многие из нас этого всё равно не застанут :D
0 Ответить
theurus
вчера в 14:02
ждем дальше. когда все провайдеры переползут тогда и нам можно будет
+3 Ответить
DreamingKitten
Никто не будет переползать (вкладываться в обучение и в настройку) пока это не будет массово
продаваться, увы. IPv6 не является selling point'ом даже для многих IT-шников.
0 Ответить
Nurked
вчера в 14:57
Ну, на самом деле не всё так плохо. Внутренние сети поднимать на ipv6 - одно удовольствие.
Получить адрес в ARIN? Занимает один день. У вас свой блок на пару ***-ардов адресов.
Пожалуйста, по ссылке. https://www.arin.net/resources/guide/ipv6/first_request/
Сделаться провайдером? Не проблема.
Майкрософт не шелохнулись, чтобы ввести IPv6 на своих сетях? Оханьки и ухоньки. Естественно.
И фиг с ними.
Обновления дебиана? Отлично обновлялся.
Настройки оборудования и маршрутов - одно удоволсьвие. Там, конечно не без приколов, но

работает.
Я разрабатывал сеть для VDS провайдера. Для клиентов в конце концов на внутренних хостах
поставили нат наружу для их же обратной совместимости. Но это тем, кому надо было. Сама
система - вся на IPv6.
Ничего, переживём.
+5 Ответить
Astroscope
вчера в 15:05
Протокол IPv6 не поддерживается ни моим домашним провайдером, ни рабочим.
Это, надо полагать, типичная ситуация вообще в мире, а не только локально у автора. Почему
провайдеры не поддерживают IPv6? Потому что это не нужно клиентам - единичные энтузиасты
не в счет, а поддержка стоит не только человекочасов, но и может потребовать аппаратного
апгрейда. И ради чего, если у всех и так все работает? Дефицит белых адресов? Да неважно,
будет больше слоев NAT.
К слову о NAT. Даже бытовой роутер является довольно эффективным экраном между этими
вашими интернетами и уютненькой локальной сетью, одним лишь только фактом своего
существования исключая значительное количество векторов атаки. Сказать по правде, я не
уверен, что бытовой роутер с еще одним NAT это хуже, чем если все эти умные (умные,
серьезно?) чайники и умные утюги будут смотреть наружу напрямую - с их-то пресловутой
склонностью вступать в ряды ботнетов или по мере своих скромных вычислительных
возможностей что-то там майнить, ведь пусть один чайник много не намайнит, но миллионы
впараллель это же уже вполне себе сила.
Дефицит адресов объективен. Все остальное оказалось никому не нужно. Пора пилить IPv7,
который будет полностью повторять известный IPv4 с единственным расширением - с еще одним,
двумя, или сколько там решат достаточным октетами для описания пространства адресов и
полной, насколько это возможно, совместимостью с IPv4, чтобы имеющееся оборудование
продолжило работать без изменений ближайшие хотя бы лет двадцать, а новое просто имело
больше возможностей. Чтобы у кого есть поддержка могли использовать новые диапазоны
адресов вместе со старыми напрямую, а у кого нет - работали только со старым диапазоном, а
новые - только через NAT.
Nurked
вчера в 15:18
Это зависит от страны. Equinix поддерживает IPv6 во всех своих зонах. Кстати, погуглите кто это
такой.
А в Лос-Анджелесе местные провайдеры уже давно прокидывают IPv6 с настроеным сверху

натом для IPv4 трансляций.
+5 Ответить
slonopotamus
вчера в 15:55
Даже бытовой роутер является довольно эффективным экраном между этими вашими
интернетами и уютненькой локальной сетью, одним лишь только фактом своего
существования исключая значительное количество векторов атаки
В этом же самом бытовом роутере есть бытовой фаерволл, который включением одной галочки
(причём включенной по умолчанию) прекрасно защищает все ваши чайники и утюги.
+8 Ответить
checkpoint
Полностью согласен на счет необходимости переходить на IPv7/IPv8, а IPv6 следует похоронить

как можно скорее.
IPv6 - это явный пример overengineering-а - вместо того, что бы банально увеличить битность
адреса, создатели IPv6 попытались впиндюрить в протокол кучу всякого бесполезного г@вна и
полностью изменили идеологию использования адресного пространства. Фактически создатели
IPv6 предлагают нам совершенно новый Интернет. Я абсолютно уерен, что все эти потуги
тщетны и IPv6 не взлетит никогда!
И еще. 128 бит на адрес это оверкилл, такие адреса совершенно невозможно запоминать и
администрировать. 64 бита для IP адреса более чем достаточно на ближайшую тысячу лет.
+8 Ответить
Aelliari
Имхо ipv6 вышел довольно стройным, и да, это совершенно новый интернет, но оно выглядит
лучше чем добавление «октетов» в ipv4.
P.S. А нафига запоминать 128 бит адреса? Тебе нужно оперировать префиксами. Да и
раздавая /64 на оконечное устройство - ты уже получишь упомянутое тобой 64 бита адреса.
Кстати, вручную сконфигурированный адрес - может быть и легко запоминаемым, для

примера - :face:b00c, ::8888. это куски без префикса
+5 Ответить
Semy
Про запоминание слышать странно. Как правило, у вас единственный префикс на всю
организацию (который достаточно быстро запоминается), вместо нескольких сетей IPv4 с
разными масками. Мне стало даже легче ориентироваться. SLAAC вам точно запоминать не
придется, а шлюзы, DNS и пр. имеют простые адреса. Некоторые админы даже придумывают
некоторые осмысленные имена, которые можно запихнуть в IPv6 типа face, dead beef и.т.д.
+3 Ответить
MiraclePtr
Некоторые админы даже придумывают некоторые осмысленные имена, которые можно

запихнуть в IPv6 типа face, dead beef и.т.д.
bad:b1g:b00b:babe:aged::18
+4 Ответить
entze
Ммм, а g то откуда? :)
0 Ответить
MiraclePtr
1 час назад
да, сорри, вместо g нужно 9
0 Ответить
Aelliari
чайники и умные утюги будут смотреть наружу напрямую
А зачем им смотреть наружу? Им можно раздать только Link-local...
+3 Ответить
FSA
Пора пилить IPv7
Вы явно недооцениваете инженеров, которые проектировали IPv6.
Цитата из книги «IPv6 для знатоков IPv4», Ярослав Тихий, 31 декабря 2013 г.:
Попробуем для начала консервативный подход. Можно ли расширить адрес IP, не

отказываясь от протокола IPv4 и, в частности, от его формата заголовка? Например, мы
могли бы поместить новые, расширенные адреса в специальные опции
IPv4. ARP справился бы с новыми адресами, так как длина адреса в нем явно указывается.
С ICMP ситуация сложнее, так как некоторые типы сообщений ICMP включают в себя
адреса IPv4. Наконец, фиксированное смещение адресов от начала заголовка облегчает
быструю аппаратную маршрутизацию пакетов, тогда как размещение адресов в опциях
значительно усложнило бы ее. Ну, и вообще говоря, опции потому так и называются, что
они должны быть факультативными, то есть необязательными для исполнения. Это
окончательный аргумент против того, чтобы новые адреса находились в опциях IPv4. В то
же время, основной заголовок IPv4 рассчитан только на 32‑битные адреса. Вывод такой,
что текущим форматом заголовка IPv4 нам все-таки придется пожертвовать, поскольку в
нем нет места для новых адресов.
Теперь, когда мы готовы распрощаться с заголовком IPv4, у нас возникает противоположное

искушение: не просто расширить адреса, а радикально переделать протокол IP, чтобы
исправить в нем существующие недостатки и добавить новые возможности.
Там есть ответы на большинство вопросов, которые тут задают в комментариях. И почему
именно 128 бит, и почему 64 бита на сеть, и почему IPv6 не совместим с протоколом IPv4, и
даже почему именно так щедро в настоящее время распределяются адреса IPv6.
Не стоит недооценивать протокол IPv6. Кроме того, что его достаточно хорошо проработали и
сделали таким каким он сейчас, учитывайте, что практически всё современное железо так или
иначе может работать с этим протоколом. Да, потребности массовой пока нет, поэтому
возможности железа ограничены. Но как только критическая масса наберётся и производители
софта для железа увидят потребность, они наклепают вам всех необходимых возможностей,
которые вам нужны и не нужны. С IPv4 также было. Софт в старых маршрутизаторах тоже был
ограничен. Но когда маршрутизаторы стали требоваться почти всем, они обросли
разухабистыми веб интерфейсами, где можно настроить кучу всего.
Сам протокол IPv6 по своей природе меньше грузит промежуточные узлы. Маршрутизаторам
проще обрабатывать эти пакеты. Если вам нужно фильтровать пакеты, то нужно опять таки
запоминать состояние. Но этого требует и NAT. Но при этом нам не нужно переписывать
заголовки пакетов, а значит наш маршрутизатор будет меньше загружен при тех же самых
возможностях, что есть в IPv4.
К слову о NAT. Даже бытовой роутер является довольно эффективным экраном между
этими вашими интернетами и уютненькой локальной сетью, одним лишь только фактом
своего существования исключая значительное количество векторов атаки.
Сравниваем. Включаем в брандмауэре вашего маршрутизатора запрет на приём пакетов, кроме

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

кроме тех, что нужны для получения ответов.
Увы, ipv6 требует для работы разрешения ICMP пакетов входящих на узлы в вашей сети. Так
что полной изоляции всё равно не получится. И никто не гарантирует, что в IoT устройстве не
найдут уязвимость в обработке ICMP. Более того — когда-то такая точно найдётся. И
защититься от неё вы уже не сможете.
+1 Ответить
FSA
Воспользуюсь вашим методом. А вы знаете, что в IPv4 используется ARP? Если ваше
устройство не отвечает на ARP запросы, то оно не сможет работать, т.е. полной изоляции не
получится. И никто не гарантирует, что в IoT устройстве не найдут уязвимость в обработке
ARP. Так что срочно нужно отказаться от IPv4!
А если серьёзно, то никто не заставляет вас все ICMP направлять напрямую без какой-либо
фильтрации на вашем брандмауэре. И есть вполне конкретные решения для защиты сети.
Они другие, не такие как в IPv4. Но и протокол у нас другой, который учитывает ошибки в
старом протоколе.
+2 Ответить
DaemonGloom
И давно требуется отвечать на arp запросы от кого попало наружу из внутреннего

периметра?
Все — никто не требует. Но конкретные виды ICMP сообщений направлять напрямую

необходимо для работы протокола согласно https://www.rfc-editor.org/rfc/rfc4890. И что-то я
пока не вижу IPS/IDS в распространённых домашних роутерах, чтобы пытаться
блокировать запросы к известным уязвимостям.
+4 Ответить
Semy
Справедливости ради, ICMPv4 тоже не рекомендуется закрывать полностью.
0 Ответить
powerman
1 час назад
Справедливости ради, ICMPv4 в локалку не требуется открывать из внешнего инета. Так

что этот аргумент мимо.
Факт в том, что IPv6 требует более сложных настроек файрвола (которые мало кто умеет
делать пока и которые вряд ли адекватно "из коробки" сделаны на всех домашних
роутерах) и требует больше пропускать из инета в локалку - т.е. уровень защищённости
локалки при использовании IPv6 падает.
+1 Ответить
NeoCode
вчера в 15:45
А что представляет собой IPv6 с точки зрения всякой цензуры/блокировок интернета и

противодействия оным? Кому он удобнее - тем кто блокирует или тем кто ищет пути обхода?
+4 Ответить
Barnaby
Тем кто обходит, нат убивает п2п-сети.
+7 Ответить
titbit
вчера в 16:00
В качестве прогноза, могу предположить, что полный переход с IPv4 не состоится никогда, скорее
интернет распадется на сегменты, которые могут быть ограниченно связанные, при этом могут
использоваться разные протоколы и будут всякие шлюзы то работающие, то нет. И это может
стать реальной технической "катастрофой" кстати, потому что связанность сильно пострадает.
+2 Ответить
jershell
Native: 43.02% 6to4/Teredo: 0.00% Total IPv6: 43.02%
https://www.google.com/intl/en/ipv6/statistics.html
Не так уж и плохо, по 5% в год переползаем потихоньку.И даже +20% за последние три года
вроде как.
aborouhin
Если там же посмотреть статистику по странам - видно, что всё это благолепие в основном за
счёт... сюрприз, Индии. Ну и ещё несколько пионеров внедрения IPv6 есть (причём какой-то
логики по географическому соседству, экономическому развитию, политической свободе и
пр. не прослеживается - в списке как Франция с Германией, но без остальных стран ЕС, так
и Малайзия и Саудовская Аравия, - так что, подозреваю, это результат стараний
национальных регуляторов). А в подавляющем большинстве стран с внедрением IPv6 или
просто грустно, или очень грустно.
0 Ответить
Loggus66
Видимо, старость мы встретим в конфигурациях "v6 для клиентов, трансляция в v4, v4 внутри
сетей", а NAT никуда не денется для LAN.
А вот работает ли фильтр интернета от РКН на IPv6, или не умеет?
0 Ответить
GennPen
А вот работает ли фильтр интернета от РКН на IPv6, или не умеет?
Раньше, до определенного времени не умел работать и обход блокировок включался

переходом на IPv6. Но сейчас уже и IPv6 фильтруют. Но, как правило, фильтруют единичными
адресами, а не подсетями.
0 Ответить
Inoriol
На работе у нас ipv6 внутренние сети (мобильный оператор в Японии, иметь больше 16
миллионов абонентов в подсети это потребность практически).
Так вот, пока самая заметная проблема ipv6 это как хреново на нём работает весь софт. Такое
ощущение что половина тестов заканчивается на этапе дуал стака и поэтому когда софт кто-то
актуально деплоит в ipv6-only начинаются пляски с конями. И часто никакая документация, по
умолчанию отрубленная поддержка и так далее и в том же духе. Короче переход на ipv6 будет
явно не простым...
Я тут хотел пример привести докер, но оказалось что в июне где-то они таки наконец
обновили документацию с тем как актуально запускать ipv6 без плясок с конями. А вот что
там было до июня и это без правил маскарада работать по дефолту вообще не будет.
iskatel
те. в 2023 году кусок документации по V6 написали в одном из основных и важных сервисов,
используемых по всему миру.
Ещё лет 10, и остальные... тоже там будут.
0 Ответить
AlexM2001
IPv6 - все там будем )
0 Ответить
php7
Раньше просто взял и забанил IP "злоумышленника" в CF или nginx
Сейчас попробуй пойми, что банить
Зачем такими большими пачками выделять на устройство?
Не будет ли с ipv6 как с "640 килобайт хватит всем"?
-4 Ответить
Aelliari
Пачки по /64 на устройство - для корректной работы slaac, чтобы анонсировал префикс - а
дальше оно само. В том числе с использованием Privacy extension для автогенерации
временных адресов
А банить - точно так же, только не адресами, а префиксами
+4 Ответить
VADemon
Давно объяснено по-моему регистрами: Если текущая политика выделения адресов окажется
ошибочной, её для следующего большого диапазона пересмотрят. У нас сейчас 2000/3 или что-
то там.
0 Ответить
Antra
Допустим, я хочу свою домашнюю сетку и кучу лаб в разных облаках перевести на IPv6.
Сейчас на IPv4 я планирую, какой кусочек из 10.x.x.x отдать в Azure, какой в AWS... Потом из них
нарезаю помельче для разных VNet, pod CIDR, service CIDR... 192.168 (чтобы не путались) для
Wireguard и прочих VPN и стыков... Естественно, никаких 169.254.0.0
C IPv6 это как должно выглядеть? Аналогично выделять внутри fdb0:42fa:e71d:48f3?
В чем тогда преимущество перед IPv4, если все равно может оказаться, что потом захочется
связаться с коллегой, у которого такая же сетка?
Вот если можно свой блок IPv6 получить "для дома, для семьи" - другое дело. Только на ARIN
вроде и есть про Requesting Space as an End User, но вроде все равно создавать организацию и
т.п. Может, конечно, гуглится устаревшая информация, но там было, мол "для домашнего
использования не даем".
0 Ответить
DaemonGloom
Считается, что провайдер выдаст клиенту /64 сетку. И большинство нормальных так и сделает,
кстати. Хотя есть и отдельные провайдеры, дающие всего один адрес на клиента — а дальше
тот уже страдает с NAT.
0 Ответить
slonopotamus
Для дома дают блок /64. А если не жадничают, то вообще /48.
+2 Ответить
Antra
Конкретный провайдер даст, когда научится в IPv6, а когда перееду отберет?
На такое я не готов завязываться, чтобы не менять всю адресацию в лабе и прочих хоум
ассистантах.
Или вы можете подсказать, у кого можно для дома действительно собственный блок получить,
который даже при переезде моим останется?
Я пока вижу только отдельные предложения типа
И вроде Hurricane Electric Free IPv6 Tunnel Broker что-то может выделить. Но это будет не
"мое", а на него завязанное. Конечно, мои нужды не mission critical. Но...
+2 Ответить
aborouhin
Вот, кстати да. А ещё даже дома, а уж тем более в офисе неплохо бы иметь пару
провайдеров для резерва. Если внутренние адреса выделять из подсети одного из них - как
оно должно работать, если этот провайдер отвалился и внешний канал переключился на
второго? Я же свой префикс /64 внешнему миру анонсировать по BGP не смогу всё равно.
+1 Ответить
DaemonGloom
С переключением адресов самое печальное. Более того, если вы попытаетесь выдавать

адреса от обоих провайдеров сразу своим компьютерам — временами всё будет ломаться
наиболее странным образом, когда маршрутизатор будет пытаться послать пакеты с обоих
сетей по одному и тому же каналу. Тут остаётся только NAT66, но с ним почти не остаётся
преимуществ самого IPv6.
0 Ответить
aborouhin
если вы попытаетесь выдавать адреса от обоих провайдеров сразу своим

компьютерам
К тому же, DHCP такой фокус просто не даст сделать.
0 Ответить
slonopotamus
Если внутренние адреса выделять из подсети одного из них
Нет, не так. Получать по адресу от каждого провайдера.
0 Ответить
aborouhin
Только DHCP не умеет выдавать одному клиенту больше одного адреса. А на смартфоне с
Android я сходу не нашёл даже способа вручную два адреса одному интерфейсу задать
(наверняка можно через командную строку, но не факт, что без рута, ну и вообще, вручную
забивать на каждый девайс по два IPv6 адреса - так себе "упрощение"). Всякие принтеры
и IoT-устройства тем более такой возможности с высокой вероятностью лишены.
В общем, как-то светлое будущее с IPv6 не вырисовывается... по крайней мере, пока,

кроме возможности получить /64 от провайдера, для любого клиента (в т.ч. мелкого и
частного) не станет такой же общераспространённой возможность анонсировать свою /64.
Но что-то мне подсказывает, что если каждый продвинутый частник или офис на 10
человек начнёт свои префиксы анонсировать - тут уже BGP чем-то заменять придётся (не
погружён в эту матчасть глубоко, так что это только в порядке дилетантской
гипотезы)
0 Ответить
slonopotamus
Я не знаю что там в BGP по поводу IPv6, но в IPv4 оно такое решето, что любой участник
может завалить порядочный кусок сети соседям, анонсировав кривую информацию.
Далеко не самый лучший протокол в мире.
+3 Ответить
slonopotamus
М.б. вы хотите ULA? Поясню, в контексте IPv6 это совершенно нормально что у устройств
есть несколько адресов. Можно одновременно иметь link-local, global, ULA (а то и несколько)
и т.д.
+1 Ответить
aborouhin
А чем ULA в IPv6 в практическом применении лучше приватных IPv4 адресов? Если всё
равно городить свою внутреннюю адресацию (а судя по всему, таки придётся) - то смысл
дёргаться, оно и с IPv4 так же работает?
0 Ответить
slonopotamus
IPv6 сделали не ради приватных адресов, они действительно ничем не лучше. Всё это
затеяно в первую очередь чтобы того чтобы иметь достаточное количество публичных.
0 Ответить
aborouhin
Но получается, что в любой минимально сложной конфигурации нам без приватных

адресов всё равно не обойтись. Несколько провайдеров или смена провайдера - см.
выше. Необходимость защиты доступа к внутренней сети через VPN? Опять. Ну и т.п.
Т.е. пока адреса IPv4 в принципе поддерживаются и доступны не за миллион денег хотя
бы в количестве 1 шт. на физическую локацию - практического смысла сейчас переводить
свои внутренние сети на IPv6 (да и вообще поддерживать у себя IPv6) для конечного
пользователя (дом, офис, любой небольшой бизнес) никакого.
А поскольку светлое будущее, в котором IPv4 уйдёт в историю, мне ничего хорошего,
кроме лишнего геморроя, тоже, похоже, не принесёт, - то и поддерживать IPv6 из идейных
соображений, приближая личным примером это будущее, тоже как-то не хочется :)
+4 Ответить
avitek
Ускоренная обработка: отсутствие контрольной суммы, в связи с чем маршрутизаторам не

нужно выполнять перерасчёт для каждого пакета.
Контрольная сумма вычисляется "на лету", по мере приёма, поэтому лишних затрат времени не
требует.
А вот что насчёт контроля целостности пакетов? Это отдано на откуп чему (или кому)?
+3 Ответить
alex_www
это задача протоколов выше, например TCP
+2 Ответить
mpa4b
TCP никак не контролирует целостность всех полей IPv4. Только некоторыx. А все поля
заголовка IPv4 тот контролирует сам, своей отдельной чексуммой. Из IPv6 зачем-то вообще
контроль целостности заголовка выпилили, прикрываясь тем, что этим должен заниматься
канальный уровень. Ну в 90ые или когда там IPv6 придумывали это было разумно, а сейчас,
когда даже 5950x раз в месяц срёт в логи machine check'ом по поводу исправления ошибки в
L3 кеше (или где там -- мне из логов не очень ясно), такое решение уже не выглядит очень
разумным. Нынче на 5 нанометрах лишних/ненужных проверок целостности не бывает.
+2 Ответить
alex_www
И не надо! Почему? Потому что именно пэйлоад чексумится на TCP уровне (L4). Кроме того
весь трафик в 100G Ethernet(L1) и далее (ну и почти все over the air интерфейсы), имеет
FEC. Чексуминг на других уровнях между L1 и L4 на практике оказался малополезным.
+1 Ответить
mpa4b
FEC езернет может иметь только в проводе, а CRC есть только от момента формирования
фрейма до момента приёма с обработкой другим концом. Далее внутри при обработке уже
либо не имеется ничего (сетвушка заботливо сложила фреймы в память компа без ECC)
либо собственные велосипеды. Флипнется битик заголовка какой на этапе отсутствия
контроля -- и в лучшем случае коннект дропнется. Чексум на заголовок IPv4 -- хороший
способ (был) для сквозного контроля целостности.
0 Ответить
czz
Между узлами — контроль целостности пусть делает L2. End-to-end — на L4 и L7.
А что там происходит внутри узла, должно ли это заботить? У узла есть свои меры для
предотвращения ошибок. Везде, где это важно, стоит ECC память. В стандарте DDR5 уже
обязательный ECC. И даже в кэшах, как вы заметили, есть чексуммы. Так что
возможностью флипа внутри узла возможно пренебречь (иначе это дефектный узел, и его
стоит поменять).
0 Ответить
Semy
И мы получаем разные алгоритмы подсчета для v4 и v6, хотя по логике OSI это не хорошо (но
кого волнует?). Ну хотя бы для UDP CRC теперь mandatory, а не optional.
0 Ответить
Survtur
Подскажите, сейчас я использую разные методы смены внешнего IP адреса, чтобы выгружать
данные, например, из инстаграма. Активно работаю через мобильные прокси, чтобы избегать
банов по IP.
Что будет, если вдруг всё начнёт работать по IPV6? Не станет ли адрес фиксированным?
UPD: Пока писал, подумал, что прокси на то и прокси, чтобы показывать свой адрес, а не мой
адрес. И раз попадается реклама прокси IPV6, то жить можно.
0 Ответить
Aelliari
фиксированным
Скорее всего, вне зависимости от метода получения ipv6 - на интерфейсе будет статический
адрес (хотя и DHCPv6 дающий разные адреса не запрещён). Но, в случае SLAAC и
работающего privacy extension - исходящие адреса будут генерироваться с некоторым
промежутком по времени (или по запросу приложения, а также не будут подходить для
входящих соединений если приложение открыв сокет - прекратит его прослушивать). Другой
вопрос что никто не помешает поступить идеологически верно, и блокнуть подсеть /64 из
которой ты обращаешься к ресурсу
+1 Ответить
alex_www
A сам RUVDS IPv6 поддерживает? На сайте упоминания нет.
+9 Ответить
ru_vds
Здравствуйте! Пока нет, и вот здесь мы рассказывали, почему.
0 Ответить
PEgorov
У меня прям флешбэки из 2011 года, когда я сидел на первом ENOG, и там прям чуть ли не
основной темой было то, что IPv4 - всё.
0 Ответить
alex_www
IPv4 - все уже лет 10 действительно. Если вы работаете в ОПСОСе в странах запада.
+2 Ответить
ivankudryavtsev
При этом блоки ipv4 дешевеют.
Просто у техногиганты решили начать монетизировать. Малые и средние компании покупают

блоки и закладывают в цену, при этом цены все равно ниже, чем у грандов.
0 Ответить
Tzimie
А как там ipv6 и ddos? Помогает больше защищающимся или тому кто атакует?
0 Ответить
kozlyuk
Сейчас IPv6 DDoS, по сути, нет. Атак на доступность не будет, если нет доступности (с) мем.
В перспективе:
Если NAT не будет распространен, можно банить /64, не опасаясь задеть легитим. Но
выше пишут, что в организациях с резервными каналами NAT может и остаться.
И этих /64 станет больше, чем сейчас /32. Пресловутый бан по GeoIP останется
актуальным.
Stateful пакетная обработка для IPv6 тяжелее, чем для IPv4, при прочих равных. State
растет, так как больше легитимных адресов и больше сами адреса.
Сами атаки не изменятся — все интересное начинается с L4.
0 Ответить
Agne
https://habr.com/ru/articles/501476/
Статья от 2020 года, изменений, к сегодняшнему дню, в сущности никаких. Может когда будет
IPv7/IPv8 , что-то улучшится. Потребностей в IPv6 у пользователей нет.
-2 Ответить
slonopotamus
Потребностей в IPv6 у пользователей нет.
То что вам что-то не нужно, не значит что оно никому не нужно.
+3 Ответить
turbotankist
Как у меня бомбит от вроде бы умных людей, разбирающихся в айти, но только поверхностно
знающих сети и говорящих, что ipv6 хуже ipv4. И молящихся на NAT (Я кстати тоже думал что он
замечает фаервол, когда был зелёным CCNA).
Вся проблема ipv6 только в том, что куча инженеров думают, что он не нужен и я не буду
поддерживать его в своей инфраструктуре. И как итог хочешь не хочешь нужно ipv4 в своей сети
тоже иметь чтобы работать с такими коллегами, а если он есть и работает, то зачем что-то
городить дополнительное.
Всё нормальное оборудование поддерживает ipv6 c 2007 года точно.
Кстати, у автора статьи нет главного отличия ipv6 от 4, которое первым пунктом во всех книжках -
отсутствие бродкаста и замена его мультикастом.
Ноют умные инженеры, что с 6 версией им неудобно тащить свои костыли и велосипеды. А вы
только подумайте сколько крутых решений не родилось, потому что ipv6 не распространён - никто
не пишет софт, который может быть будет работать у 25% пользователей.
+3 Ответить
Antra
И молящихся на NAT (Я кстати тоже думал что он замечает фаервол, когда был зелёным
CCNA).
Не заменяет, а служит дополнительным рубежом обороны. Так же, как отсутствие маршрутов к
"жертве" существенно усложняет жизнь атакующему.
И так же, как фаервол не является "серебряной (золотой?) пулей", обеспечивающей 100%
защиту, а нужно вкладываться и во всякие WAF, и обеспечивать безопасность цикла
разработки...
Вся проблема ipv6 только в том, что куча инженеров думают, что он не нужен и я не буду
поддерживать его в своей инфраструктуре.
Да у многих компаний в лабах он развернут. И даже в отдельных сегментах. Чисто опыта

набраться. Ибо в продуктив выставлять действительно мотивации не особо много (за
исключением кейсов типа "сотовый оператор").
Мне вот интересно было IPv6 пощупать, причем не на адресах, "какие сами назначутся", а
более приближено к реальности. Взял сетку /56, которую Oracle Cloud раздает в рамках Always
Free, побил на более мелкие, поиграл с ней на наскольких тестовых сайтах. На Российском VPS
(где провайдер выдаетIPv6) поднял Nginx reverse proxy на IPv6...
Пощупал, поиграл, и на этом все закончил. ибо внятных кейсов, где это помогло бы мне или
моим заказчикам, не придумал.
Совершенно новые (и при этом весьма большие) внедрения - ну возможно. Но переделывать

существующее - очень вряд ли.
+3 Ответить
ValdikSS
51 минуту назад
Пока появляются такие статьи с аргументами буквально: «у меня не открылся Github, IPv6
отстой!» (видимо, электромашины тоже отстой, раз «заправок» сильно меньше), мир
строит IPv6-only сети.
0 Ответить

IPv6 - это катастрофа (но поправимая) - Хабр

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

IPv6 - это катастрофа (но поправимая) - Хабр

Загружено:

Авторское право:

Доступные форматы

8/14/23, 4:04 PM IPv6 — это катастрофа (но поправимая) / Хабр

IPv6 — это катастрофа (но поправимая)

Блог компании RUVDS.comСистемное администрирование*Сетевые технологии*IPv6*

Автор оригинала: Mathew Duggan

Почему IPv6 стоит приложенных усилий?

Заголовок пакета IPv6

Пространство адресов (это очевидно).

Меньше полей заголовков (8 против 13 в v4).

Ускоренная обработка: отсутствие контрольной суммы, в связи с чем маршрутизаторам не

Настройка сервера исключительно на IPv6

Важно: противьтесь желанию оптимизировать использование адресов. Общаясь с более

Подсеть Адрес подсети

Для /52 принцип тот же:

Подсеть Адрес подсети

Вы по-прежнему можете сразу понять, какая перед вами подсеть.

▍ Проблема 1 — не могу подключиться по SSH

▍ Проблема 2 — не могу использовать GitHub

▍ Проблема 3 — не могу настроить Datadog

Хорошо. Я проделаю всё вручную через apt.

0% [Connecting to apt.datadoghq.com (18.66.192.22)]

Другие VM обходятся чуть дороже, но ненамного.

Надеюсь, что в итоге договорюсь с промежуточными провайдерами и смогу расширить

Я: Было бы здорово, если бы вы рассказали о каких-нибудь технических деталях своего проекта.

Каспер: Сразу видно — свой человек :-)

Я могу углубиться в детали очень сильно.

Сайт оригинала статьи

Docker предупреждает, что данная конфигурация не готова к использованию в продакшене. Я не

Теперь у меня в Nginx загружен сертификат Origin из Cloudflare с настроенной функциональностью

Отлично. Сайт налажен и работает.

Мои контейнеры по-прежнему не могут взаимодействовать с ресурсами IPv4 несмотря на то,

Почему бы не продолжать использовать IPv4?

Если разбить балансировщик нагрузки на составляющие, то он выполняет две задачи: распределяет

Балансировать нагрузку можно множеством способов, но самыми распространёнными являются

1. Round-robin. Круговая обработка запросов на подключение.

2. Weighted Round-robin. Взвешенная круговая обработка, в результате которой сервера получают

принесло бы ощутимую ценность.

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх 🕹️

Теги: ruvds_переводipv6ipv4сетевые технологииоблачные технологииdnsnat64

Хабы: Блог компании RUVDS.comСистемное администрированиеСетевые технологииIPv6

Telegram ВКонтакте Twitter

Дмитрий Брайт @Bright_Translate

то что IPv6 представляли как "серебряную пулю"

А еще миллионы (если не миллиарды) сетевых железяк, которые никак IPv6 не

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

Причём 100% поддержки нет по сей день.

Отличный и продуманный дизайн - впрочем все уже оценили по внедрению.

По поводу первого - категорически несогласен. Как показывает практика, у современных

По поводу второго - возражений нет.

Основная проблема внедрения IPv6 - это нежелание людей разбираться в новом

Вы это хотите сказать всем пользователям интернета?

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

"Связность каждый сети с каждой" - это бесполезное свойство, которое оказалось

"Связность каждый сети с каждой" - это бесполезное свойство,

Вот чтобы не повторяться, по поводу невостребованности

"Связность каждый сети с каждой" - это бесполезное свойство, которое оказалось

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

Если у вас во внутреннем контуре IPv6, то какой? И почему не site-local?

Высшее достижение NAT-строения - Carrier grade NAT у сотовиков. Врагу такого не

Безусловно. Я вообще за эшелонированную защиту.

Интернет-фаервол - DMZ - Другой фаервол - бэкбон - ЦОД фаервол - серверные сегменты

Причем на Интернет фаерволе даже маршрутов в сторону "корпоративной сети" нет. Он

Где бы и кто бы ни ошибся - внутренний сервер из ЦОД не окажется внезапно exposed.

Не совсем только понятно, почему в этой схеме не может быть ipv6?

Блог компании RUVDS.comСистемное администрированиеСетевые технологииIPv6*