Это выгодно в первую очередь провайдерам, это выгодно крупным компаниям с крупными сетями - банкам, страховым компаниям. Это не умозрительно, это высказываемый ими интерес, обсуждаемый на конференциях - на Cisco Live, на IPv6 Council, на различных NOG, на конференции ARCEP.
Поддерживает ли ваш роутер политики IP SLA? Если да, то вы можете создать сессии тестирования до неких устройств в глубинвх сети каждого аплинка и регулярно их зондировать (политики весма гибки как по испльзуемым протоколам, так и по критериям отказа). В зависимости от статуса SLA для каждого аплинка, вы можете менять метрики маршрутов или вообще убирать их из таблицы.
Получить свою AS и свой пул IPv6 - это лучшее решение и не слишком затратное (можно получить статус PI договорившись с каким-нибудь LIR'ом). Вопрос обычно упирается в необходимость поднятия BGP с каждым из ваших провайдеров-аплинков, которые не предусматривают BGP c публичными абонентами. Но в России по знакомству и не такое бывает. :) Лучшее - потому что при потере канала ваши устройства не вынуждены менять префикс и переключение возможно без потери соединений (при условии приемлимого времени конвергенции сети). Так же это решение позволяет поддерживать каналы в режиме актив/актив и балансировать трафик между ними.
Чаще всего для частника такое решение недоступно. Так что вариант описаный inkelyad наиболее реальный - получить префикс от каждого из аплинков и раздать всем устройствам в сети.
Можно ли создать политику маршрутизации для группы по их мак адресам - в принципе да, особенно если вы используете EUI-64, тогда MAC адреса используются в создании сетевых адресов устройств (независимо от получаемых префиксов), а значит можно использовать L3 ACL на основе IP адресов ваших устройств. Впрочем, это зависит от возможностей роутера.
Вообще, есть еще вариант с адресами ULA для устройств и использовать NPT66 для замены префикса ULA на префикс активного аплинка и в случае падения основного аплинка - транслировать префикс ULA на префикс запасного аплинка (а затем и третьего). Эта конфигурация работает, но не рекомендуется, потому что является костылем и сводит на нет преимущества "чистого" IPv6 без NATа.
Я, к сожалению, очень мало сталкиваюсь с публичными маршрутизаторами начального или SOHO уровня, потому не могу ответить с уверенностью. Но в роутерах устанавливаемых провайдером своим абонентам такое встречается. И не только прошивка IPv4Only, но и разный обьем поддержки IPv6. Например Freebox не поддерживает DHCPv6, а только SLAAC. Считать ли, что Freebox не умеет IPv6?
Что значит "норм"? Для мобильного абонента - чаще всего да, он ограничен только своим терминалом. Для фиксированного подключения, где абонент - это вся его домашняя сеть (со всеми смартфонами, ноутбуками, компами, хбоксами и т.д.) рейт 1:100 даст 650 доступных портов. По нашим исследованиям это на пределе среднего потребления среднестатистической семейной сетью. В пике доходит до 2000 соединений. С учетом возможного роста мы резервируем 8000 портов на абонента, так что 1:100 превращается в 1:8. Ну и далее вопрос в количестве абонентов.
Почему неправильно? Это вполне нормально, серверу для коммуникации с интернетом вполне достаточно одного адреса. Все сервера в одном VLAN получат адреса /128 в общей подсети /64 этого VLAN. Скорей интересно зачем серверу собственный делегируемый префикс, под какие задачи?
Нельзя ответить на "сферический вопрос в вакууме". Есть ли выгода и какова она - зависит от бизнеса компании. Для провайдеров это избегание покупки IPv4 и оптимизация и повышение эффективности тренспортной сети, для хостеров и облачников - новый уровень работы с приложениями и контейнерами, упрощение автоматизации развертывания хостов, для сетевых программистов - упрощение работы со стеком... Для компании производящей болты, шурупы и проволочки для бутылок шомпанского - наверно никакой. Тысячи случаев и в каждом случае своя ситуация.
Всегда пожалуйста! :) На самом деле это один из самых интересных проектов сам по себе, так как в кои-то веки создатели протокола имели достаточно времени учесть ошибки прошлого и сделать систему "по уму". Изящество многих решений меня весьма впечетляет. Можно изучать просто для удовольствия.
В теории несложно. На практике же... Одно дело провайдерское оборудование (включая провайдерский роутер дома у пользователя), другое дело - личное оборудование пользователя. Даже у провайдера процесс обнаружения проблем, выпуск патчей, их тестирование, процесс обновления - это очень сложный процесс, да и то, есть место лени и халатности. Чего уж говорить про обычного пользователя, котрый даже при критическом обновлении винды может до последнего тянуть с необходимой перезагрузкой?
Нет, не так дорого. Например, требования к поддержке IPv6 включаются в список критериев при выборе нового оборудования (в цикле его регулярного обновления), в список требований дизайна архитектуры новых проектов, в список критериев при выборе нового ПО, разрабатывается план адресации IPv6 компании, включаются в требования к выбору провайдеров-аплинков и т.д. IPv6 внедряется по принципу best-effort, оказией, подспудно. Железо и программы не поддерживающие IPv6 вполне возможно сами уйдут в процессе цикла обновления еще до момента реального перехода на IPv6 компанией, а с другой стороны, вы будете уверены, что железо и софт, установленные на момент перехода, совместимы с IPv6. Такая постепенная миграция в фоновом режиме экономит время и усилия инженеров и менеджеров, требует куда меньших затрат и главное - позволяет избежать ошибок дизайна и сюрпризов в момент самого перехода. Параллельно это позволяет натренировать кадры (а точнее позволить кадрам самообучиться). Менеджменту легче согласиться на расход несколькх часов в неделю/ в месяц на этот фоновый процесс, нежели запускать революционный проект прехода на IPv6, с кучей инженеров, тестировщиков, шефом проекта, KPI, планингом и дедлайном. А главное с риском аварии в момент перехода или с упущением чего-то важного.
Да можно закрыть на время глаза заплатив за покупку IPv4 адресов. А если прогноз роста потребности - сотни тысяч адресов? Миллионы? Это не инвестиции, это просто потери, они не вернутся.
Скажем так, у всех известных мне крупных западных публичных провайдеров, поставлямый провайдером пользовательский роутер имеет на борту файервол активный для IPv4 и для IPv6 для внешних входящих соединений. Если внутри домашней сети есть уже зомбированное оборудование, то дефолтная политика файервола заблокировать эти соединения не в состоянии. В этом плане нет никакой разницы между IPv4 и IPv6.
Я понимаю о чем вы хотите сказать и NAT действительно создает иллюзию большей защищенности нежели возможность соединений без трансляции. Но это является одним из распространенных мифов о IPv4 vs IPv6. Механизмы заражения устройств ботнетами весьма разнообразны и некоторые проходят в несколько этапов, зачастую с преодолением NAT в итоге.
Что IPv4 с NAT, что IPv6, оба нуждаются в файерволе, потому сравнивать безопасность "открытых всем ветрам" конфигураций попросту некорректно.
Там кажется, что много, потому что базовые стандарты сформулированы как список отдельных тестов, по одному тесту на каждую функцию или параметр.
Это хороший документ. Но лого не только для этого, оно упрощало проверку соответствия стандарту, потому что многие производители указывали поддержку того или иного RFC, но либо реализовывали ее не в полном обьеме, либо трактовали стандарт при реализации на свой лад (особенно там где RFC оговаривал "should", а не "must").
Я даже не соменеваюсь, что мир за пределами российского сегмента вымышлен. :) Но в этом вымышленном мире доступные блоки у всех RIR закончились еще несколько лет назад, а цена за покупку IPv4 хоть и упала, но держится на уровне $20-30 за адрес в зависимости от размера блока. https://www.ipv4.global/all-ipv4-pricing-data/
Так что если вы даже небольшой провайдер с несколькоми сотнями тысяч абонентов, то можете произвести самостоятельно несложный арифметический расчет ваших инвестиций в этот неисчерпаемый ресурс.
Что поделать... это проблемы роста. Они пройдут. Даже 20 лет назад было сложно обьять все возможные кейсы и нюансы в переходе к IPv6, сейчас мир IT сильно разросся, стало еще многообразнее и сложнее. Одни технологии ушли в музей, другие стали стандартом по умолчанию. Нормальный процесс эволюции.
Смотря что подразумевать под домашними устройствами. Клиенты? - телевизоры, пылесосы, утюги, видеокамеры? Им требуется лишь базовая поддержка стека - SLAAC, DHCPv6, DNSv6 - собственно этого достаточно чтобы соответствовать наклейке "IPv6 Ready". Что вполне справедливо, ибо "мы поддерживаем и готовы, а есть ли у вас IPv6 - это уже не наша проблема".
Или речь идет о маршрутизаторе? Если роутер предоставляется провайдером, то его форма поддржки IPv6 определяется дизайном принятым самим провайдером, ибо должен определять как роутер получает параметры IPv6 и какие именно (размер делегируемого префикса? поддерживает ли роутер DHCPv6 для LAN клиента или только SLAAC? как сам роутер получает PD, DNSv6, NTPv6 - SLAAC? DHCPv6? через PPP? есть ли сервис IP-TV? mcast v6? есть ли SIP телефония v6 и как она шифруется/тунелируется? Поддерживается ли IPv4 как DualStack или происходит трансляция NAT46 в MAP-T или MAP-E? и т.д.)
Схожий список вопросов если вы используете свой собственный роутер (или файервол) в дополнение к провайдерскому или вместо него. Если провайдерский роутер не позволяет пользователю прописывать статические маршруты (а это часто именно так) и не поддерживает DHCPv6, то получить префикс для сегмента за вашим личным роутером или файерволом будет весьма затруднительно. Да и то, ваш роутер должен поддерживать прокси-icmpv6, что стандартизировано, но ни разу не видел в реальности (кроме как в документации некоторых Cisco). Даже для работе с DHCPv6 ваш роутер должен поддерживать DHCPv6 relay.
Так что то, что вы можете получить в реальности напрямую зависит от того, что и как провайдер способен вам предоставить.
Поддерживает. Начиная с v11. В том числе DHCPv6-PD, что горячо обчуждалось месяц назад на UK IPv6 Council:
https://www.ipv6.org.uk/wp-content/uploads/2025/10/11_Enterprise_Android_DHCPv6PD_VMcKillop.pdf
https://www.ipv6.org.uk/wp-content/uploads/2025/10/10_Android-DHCPv6PD_RichPatterson.pdf
Почему нет? Контейниризации это тоже своеобразная виртуализация. Я видел пример с назначением отдельного /128 каждому контейнеру.
Это выгодно в первую очередь провайдерам, это выгодно крупным компаниям с крупными сетями - банкам, страховым компаниям. Это не умозрительно, это высказываемый ими интерес, обсуждаемый на конференциях - на Cisco Live, на IPv6 Council, на различных NOG, на конференции ARCEP.
Поддерживает ли ваш роутер политики IP SLA? Если да, то вы можете создать сессии тестирования до неких устройств в глубинвх сети каждого аплинка и регулярно их зондировать (политики весма гибки как по испльзуемым протоколам, так и по критериям отказа). В зависимости от статуса SLA для каждого аплинка, вы можете менять метрики маршрутов или вообще убирать их из таблицы.
Получить свою AS и свой пул IPv6 - это лучшее решение и не слишком затратное (можно получить статус PI договорившись с каким-нибудь LIR'ом). Вопрос обычно упирается в необходимость поднятия BGP с каждым из ваших провайдеров-аплинков, которые не предусматривают BGP c публичными абонентами. Но в России по знакомству и не такое бывает. :) Лучшее - потому что при потере канала ваши устройства не вынуждены менять префикс и переключение возможно без потери соединений (при условии приемлимого времени конвергенции сети). Так же это решение позволяет поддерживать каналы в режиме актив/актив и балансировать трафик между ними.
Чаще всего для частника такое решение недоступно. Так что вариант описаный inkelyad наиболее реальный - получить префикс от каждого из аплинков и раздать всем устройствам в сети.
Можно ли создать политику маршрутизации для группы по их мак адресам - в принципе да, особенно если вы используете EUI-64, тогда MAC адреса используются в создании сетевых адресов устройств (независимо от получаемых префиксов), а значит можно использовать L3 ACL на основе IP адресов ваших устройств. Впрочем, это зависит от возможностей роутера.
Вообще, есть еще вариант с адресами ULA для устройств и использовать NPT66 для замены префикса ULA на префикс активного аплинка и в случае падения основного аплинка - транслировать префикс ULA на префикс запасного аплинка (а затем и третьего). Эта конфигурация работает, но не рекомендуется, потому что является костылем и сводит на нет преимущества "чистого" IPv6 без NATа.
Я, к сожалению, очень мало сталкиваюсь с публичными маршрутизаторами начального или SOHO уровня, потому не могу ответить с уверенностью. Но в роутерах устанавливаемых провайдером своим абонентам такое встречается. И не только прошивка IPv4Only, но и разный обьем поддержки IPv6. Например Freebox не поддерживает DHCPv6, а только SLAAC. Считать ли, что Freebox не умеет IPv6?
У меня сейчас около 900 открытых соединений tcp+udp из моей локальной сети в интернет, хотя тоже не показательный случай.
Приведенные мною выше цифры результат внутреннего исследования французского оператора (одного из большой четверки).
Позвольте переадресовать вас к статье Geoff Huston "The IPv6 transition", где он прекрасно изложил все причины торможения этого перехода.
https://blog.apnic.net/2024/10/22/the-ipv6-transition/
Что значит "норм"? Для мобильного абонента - чаще всего да, он ограничен только своим терминалом. Для фиксированного подключения, где абонент - это вся его домашняя сеть (со всеми смартфонами, ноутбуками, компами, хбоксами и т.д.) рейт 1:100 даст 650 доступных портов. По нашим исследованиям это на пределе среднего потребления среднестатистической семейной сетью. В пике доходит до 2000 соединений. С учетом возможного роста мы резервируем 8000 портов на абонента, так что 1:100 превращается в 1:8. Ну и далее вопрос в количестве абонентов.
Почему неправильно? Это вполне нормально, серверу для коммуникации с интернетом вполне достаточно одного адреса. Все сервера в одном VLAN получат адреса /128 в общей подсети /64 этого VLAN. Скорей интересно зачем серверу собственный делегируемый префикс, под какие задачи?
Нельзя ответить на "сферический вопрос в вакууме". Есть ли выгода и какова она - зависит от бизнеса компании. Для провайдеров это избегание покупки IPv4 и оптимизация и повышение эффективности тренспортной сети, для хостеров и облачников - новый уровень работы с приложениями и контейнерами, упрощение автоматизации развертывания хостов, для сетевых программистов - упрощение работы со стеком... Для компании производящей болты, шурупы и проволочки для бутылок шомпанского - наверно никакой. Тысячи случаев и в каждом случае своя ситуация.
Всегда пожалуйста! :) На самом деле это один из самых интересных проектов сам по себе, так как в кои-то веки создатели протокола имели достаточно времени учесть ошибки прошлого и сделать систему "по уму". Изящество многих решений меня весьма впечетляет. Можно изучать просто для удовольствия.
В теории несложно. На практике же... Одно дело провайдерское оборудование (включая провайдерский роутер дома у пользователя), другое дело - личное оборудование пользователя. Даже у провайдера процесс обнаружения проблем, выпуск патчей, их тестирование, процесс обновления - это очень сложный процесс, да и то, есть место лени и халатности. Чего уж говорить про обычного пользователя, котрый даже при критическом обновлении винды может до последнего тянуть с необходимой перезагрузкой?
Нет, не так дорого. Например, требования к поддержке IPv6 включаются в список критериев при выборе нового оборудования (в цикле его регулярного обновления), в список требований дизайна архитектуры новых проектов, в список критериев при выборе нового ПО, разрабатывается план адресации IPv6 компании, включаются в требования к выбору провайдеров-аплинков и т.д. IPv6 внедряется по принципу best-effort, оказией, подспудно. Железо и программы не поддерживающие IPv6 вполне возможно сами уйдут в процессе цикла обновления еще до момента реального перехода на IPv6 компанией, а с другой стороны, вы будете уверены, что железо и софт, установленные на момент перехода, совместимы с IPv6. Такая постепенная миграция в фоновом режиме экономит время и усилия инженеров и менеджеров, требует куда меньших затрат и главное - позволяет избежать ошибок дизайна и сюрпризов в момент самого перехода. Параллельно это позволяет натренировать кадры (а точнее позволить кадрам самообучиться). Менеджменту легче согласиться на расход несколькх часов в неделю/ в месяц на этот фоновый процесс, нежели запускать революционный проект прехода на IPv6, с кучей инженеров, тестировщиков, шефом проекта, KPI, планингом и дедлайном. А главное с риском аварии в момент перехода или с упущением чего-то важного.
Да можно закрыть на время глаза заплатив за покупку IPv4 адресов. А если прогноз роста потребности - сотни тысяч адресов? Миллионы? Это не инвестиции, это просто потери, они не вернутся.
Скажем так, у всех известных мне крупных западных публичных провайдеров, поставлямый провайдером пользовательский роутер имеет на борту файервол активный для IPv4 и для IPv6 для внешних входящих соединений. Если внутри домашней сети есть уже зомбированное оборудование, то дефолтная политика файервола заблокировать эти соединения не в состоянии. В этом плане нет никакой разницы между IPv4 и IPv6.
Я понимаю о чем вы хотите сказать и NAT действительно создает иллюзию большей защищенности нежели возможность соединений без трансляции. Но это является одним из распространенных мифов о IPv4 vs IPv6. Механизмы заражения устройств ботнетами весьма разнообразны и некоторые проходят в несколько этапов, зачастую с преодолением NAT в итоге.
Что IPv4 с NAT, что IPv6, оба нуждаются в файерволе, потому сравнивать безопасность "открытых всем ветрам" конфигураций попросту некорректно.
Там кажется, что много, потому что базовые стандарты сформулированы как список отдельных тестов, по одному тесту на каждую функцию или параметр.
Это хороший документ. Но лого не только для этого, оно упрощало проверку соответствия стандарту, потому что многие производители указывали поддержку того или иного RFC, но либо реализовывали ее не в полном обьеме, либо трактовали стандарт при реализации на свой лад (особенно там где RFC оговаривал "should", а не "must").
Я даже не соменеваюсь, что мир за пределами российского сегмента вымышлен. :) Но в этом вымышленном мире доступные блоки у всех RIR закончились еще несколько лет назад, а цена за покупку IPv4 хоть и упала, но держится на уровне $20-30 за адрес в зависимости от размера блока. https://www.ipv4.global/all-ipv4-pricing-data/
Так что если вы даже небольшой провайдер с несколькоми сотнями тысяч абонентов, то можете произвести самостоятельно несложный арифметический расчет ваших инвестиций в этот неисчерпаемый ресурс.
Что поделать... это проблемы роста. Они пройдут. Даже 20 лет назад было сложно обьять все возможные кейсы и нюансы в переходе к IPv6, сейчас мир IT сильно разросся, стало еще многообразнее и сложнее. Одни технологии ушли в музей, другие стали стандартом по умолчанию. Нормальный процесс эволюции.
Смотря что подразумевать под домашними устройствами. Клиенты? - телевизоры, пылесосы, утюги, видеокамеры? Им требуется лишь базовая поддержка стека - SLAAC, DHCPv6, DNSv6 - собственно этого достаточно чтобы соответствовать наклейке "IPv6 Ready". Что вполне справедливо, ибо "мы поддерживаем и готовы, а есть ли у вас IPv6 - это уже не наша проблема".
Или речь идет о маршрутизаторе? Если роутер предоставляется провайдером, то его форма поддржки IPv6 определяется дизайном принятым самим провайдером, ибо должен определять как роутер получает параметры IPv6 и какие именно (размер делегируемого префикса? поддерживает ли роутер DHCPv6 для LAN клиента или только SLAAC? как сам роутер получает PD, DNSv6, NTPv6 - SLAAC? DHCPv6? через PPP? есть ли сервис IP-TV? mcast v6? есть ли SIP телефония v6 и как она шифруется/тунелируется? Поддерживается ли IPv4 как DualStack или происходит трансляция NAT46 в MAP-T или MAP-E? и т.д.)
Схожий список вопросов если вы используете свой собственный роутер (или файервол) в дополнение к провайдерскому или вместо него. Если провайдерский роутер не позволяет пользователю прописывать статические маршруты (а это часто именно так) и не поддерживает DHCPv6, то получить префикс для сегмента за вашим личным роутером или файерволом будет весьма затруднительно. Да и то, ваш роутер должен поддерживать прокси-icmpv6, что стандартизировано, но ни разу не видел в реальности (кроме как в документации некоторых Cisco). Даже для работе с DHCPv6 ваш роутер должен поддерживать DHCPv6 relay.
Так что то, что вы можете получить в реальности напрямую зависит от того, что и как провайдер способен вам предоставить.