Использую на двух списаных ноутбуках Dell X1 20-летней давности в качестве переносных консолей для подключения к маршрутизаторам в датацентре. Нужны только эмулятор терминала и wireshark. Есть и современные ноуты, но Dell X1 во многом идеален и не хочу выкидывать из сентиментальных чувств. Прочие минималистичные дистрибутивы притормаживают, TinyCore летает.
Понравилась организация работы с приложениями, где каждое приложение монтируется как маленькая файловая система. Своеобразная контейниризация.
Ничего необычного в моем кейсе нет, но позволило продлить жизнь старому прекрасно работающему железу.
Интересно. Точнее интересная политика, хотя видимо подход как в штатах - либо аренда, либо свой собственный роутер. В Европе провайдер по умолчанию предоставляет свой роутер, это входит в абонемент. Хотя можно обойтись своим собственным оборудованием, но это исключительно гики, их доли процента. Потому вопросов совместимости не стоит ни у провайдера, ни у абонентов.
Конечно такой сервис как Youtube не станет просто так и себе в убыток отказываться от части своей аудитории и части своих доходов просто в угоду неким высоким идеям. Естественно во главе стоит здоровый прогматизм. Колличество просмотров (не важно через какой стек) конвертируется в колличество показов рекламы, а из показов - в финансовые доходы. Если принять гипотезу, что доля просмотров через IPv6 будет расти, а доля просмотров через IPv4 будет снижаться, то в какой-то момент последняя сравняется с расходами компании на поддержание этого стека (на лоадбалансеры, на CDN ящики, лицензии и т.д.) и в этот момент компания прекратит поддержку IPv4 (даже при том, что некая доля клиентов IPv4 еще останется). Или не прекратит, если посчитает, что имиджевые потери больше чем технические. Или прекратит раньше, посчитав, что поддержка единственного стека выгоднее в среднесрочной перспективе. Или если будет какое-то давление или наоборот - преференции со стороны регуляторов и политиков.
Я не думаю, что у нас с вами есть разночтения в этом плане.
В целом я полностью согласен с вашей оценкой. В действительности так и просходит и мы прошли через это - от IPv4Only, на DualStack (сейчас это 5/6 парка абонентов xDSL/FTTH), CGNAT чтобы выиграть время на разработку и тестирование MAP-T и наконец сам MAP-T. Коллекты (от доступа до BNG) DualStack, что позволяет иметь абонентов всех типов в общем коллекте и легко мигрировать из одного типа в другой. Например абонент которого не устраивает MAP-T имеет возможность переключиться обратно на DualStack (это менее 1% от мигрированных на MAP-T). Это решает в том числе проблему несовместимости CPE абонента. В ближайшее время вопрос отключения IPv4 в коллектах в планах не стоит, но в перспективе, с обновлением парка и/или миграцией подавляющего большинства абоенентов на IPv6 - не проблема. То есть в конечном итоге - да, когда-нибудь, предвидится.
Я единственное не понял, откуда 200-300 моделей роутеров? Имеются в виду CPE предоставляемые провайдером? У нас дай бог десяток моделей наберется, бОльший зоопарк провайдеру тянуть смысла нет. Пользовательские собственные CPE? Можно, но абонент либо поддерживает MAP-T, либо запрашивает возврат своей линии на DualStack и тогда использует стандартный набор параметров DHCPv4/v6.
От ошибок и недочетов в дизайне и в реализации не застрахован никто. Но есть SPOF которые присутствуют изначально, они заложены в самой архитектуре. Например PON или телефонный коллектор не имеют резерва изначально, потеря OLT или DSLAM априори означают потерю всех подключенных к ним абонентов. В противоположенность им подсистема DNS всегда строится с избыточностью, но это не означает, что ошибка в скрипте не может гипотетически положить все сервера разом. Потому есть оценка надежности, есть вероятность отказа, есть методика использования схожих систем от разных производителей чтобы минимизировать риски, есть тесты BCP, есть "план B" для соблюдения SLA даже когда отказывает то, что не должно было отказать.
Это просто ориентировочные сроки, необходимые для развертывания IPv6 как такового. А дана ли команда на разворачивание, в каком обьеме, в каком ритме, с какими целями - это уже другой вопрос. Каждый провайдер здесь сам себе Буратино.
Да нет, вполне. Цикл плановой смены оборудования в среднем 5-10 лет, апгрейдов оборудования 4-7 лет (сильно зависит от роли оборудования), обновления софта - 2-3 года. На развертывание IPv6 с нуля (со всеми перечисленными пунктами) в среднем уйдет 1,5-2 года (если не форсировать). Если для развертывания требуются фичи, которые доступгы только в новых версиях и требуется обновление - развертывание обычно координируется с плановым обновлением. Это может сдвинуть время развертывания до 2-3 лет. Если требуется увеличение физической емкости - здесь зависит от конкретной ситуации, конкретного оборудования и его производителя, какого ресурса конкретно не хватает и оценки рисков и рынка. Может привести к дополнительной задержке, а может нет. В любом случае 3-4 года на разворачивание с нуля крупным провайдером это вполне рациональная оценка.
Плюс на это накладывается анализ рынка и планирование бюджета - обычно на 2 горизонта: на 3 года и на 5-6 лет вперед, что тоже кореллирует с оценкой развертывания.
Это просто туннелирование, оно никоим образом не решает вопрос оперирования конечных устройств по новому протоколу и фактически означает не-переход на новый протокол.
Учитывая цикл обновления оборудования провайдерами и пересмотра архитектуры, я думаю, что в ближайшие 5 лет основной тренд будет в переводе публичных ресурсов на DualStack и предоставление IPv6 по умолчанию. Сама миграция (включая внутренние сети) - ближайшие 10-15 лет.
Включить пространство v4 в v6 это не проблема вообще. Проблема во всем прочем - нельзя было сделать обратную совместимость, даже просто увеличив поля под адреса в заголоке. Проблема не в IPv6, а в IPv4, последний не поддается модернизации.
Но опять же, решить только проблему нехватки адреса - это костыль, который не решал прочие врожденные недостатки IPv4. И когда стало ясно, что совместимости не будет даже при минимальных изменениях, то было решено создать новый протокол с нуля и заодно исправить недочеты предыдущего протокола. И это правильно.
ну такое себе. во-первых, это сразу сильно сужает выбор провайдеров.во-вторых, вероятность того, что два канала одного провайдера перестанут работать вместе, остаётся высокой.
Спрос рождает предложение. Сейчас найти такие предложения не составит труда, все провайдеры работающие с сегментом B2B в состоянии предложить подобное решение. Тем более, что такие решения не тербуют капитальных затрат для провайдера, ни на оборудование, ни на архитектуру. Связка технологий дана для примера, это может быть FTTx+Mobile, FTTx+xDSL, FTTx+SAT и т.д. или в любых других комбинациях и технологиях. Даже для связки +Mobile не обязательно быть сотовым оператором, можно быть MVNO. B2B вообще гораздо более гибок в этом плане.
То, что два канала одного провайдера перестанут работать вместе очень низка, так как возможные SPOF могут быть только на уровне сетей доступа, а все что выше, начиная от агрегационных сетей и бекбона, имеет избыточность как минимум n+1. Сети наземного доступа и мобильного доступа (RAN) это физически раздельные сети (как минимум до уровня агрегации), а глобальный инцидент если и возможен, то провайдер имеет контрактное обязательство устранить неполадки в течении согласованного времени (SLA обычно 4 часа). Вот если гипотетический простой в 4 часа неприемлим для клиентского бизнеса, то подключаться к двум разным провайдерам имеет смысл.
так-то оно так, но адреса ipv4 кончились уже несколько лет как, но их можно купить/арендовать, плюс цена за адрес снижается.
Можно. Но это как из детской сказки - сколько можно сделать шапок из одной шкуры? 2 можно? Можно. А 3? Можно. А 5? Можно. Хоть 10, если не оговаривать размер получаемых шапок. Так и с IPv4. Можно выкручиваться, докупать адреса, ставить динамический CGNAT и начинать шарить каждый адрес на все большее и большее количество абонентов. Можно так делать? Конечно! Работать будет? Вполне. Некоторое время. Только доступный абонентам сервис будет все уже и уже. Доступ извне? Зачем? P2P сети? Ненужно. SIP телефония? Не скрепно. И т.д. Итог один : вместо поредоставления доступа в интернет, вы предоставляете некий доступ к некому сервису. "Доступ к VK и Госуслугам из дома", "чат с друзьями в MAX", "видео с Рутуба". Остальные пртоколы и сервисы вам не нужны, значит и нечего огрод городить. Тем более заморачиваться с IPv6 от которого ничего кроме головной боли. Мы как-то проглядели момент, когда временное и приносящее неудобства и ограничения решение NAT на IPv4 стало теплым и ламповым, а полноценная свобода доступа в инет стала пугающей и ненужной.
Кстати, цены на блоки IPv4 снижались, но похоже стабилизировались и начинают снова расти в цене. Есть много трактовок причин, суть в том, что это не принципиальное падение интереса к IPv6, а не более чем отсрочка в процессе перехода.
вот смотрите, есть город, есть сотни магазинов в нём.магазинам нужен бесперебойный интернет (эквайринг и всё такое). обычно это решается резервным каналом связи. в вашей картине мира нужно получать по AS на каждый магазин?
Нет, конечно. Все же выриант с AS это тотальное решение, когда сеть должна иметь не только резервный канал, но еще и через независимого провайдера. В большинстве случаев для малых клиентов такое резервирование черезмерно, достаточно резервирования через два канала одного провайдера, но по разным технологиям - например FTTO + 4G/5G. В этом случае гараздо проще предоставить клиетну один и тот же PD через оба пути. Клиент защищен от сбоев в разных сетях доступа (Landed vs RAN), а там где общая часть провайдеской сети (бекбон, пиринги) - SLA контракта с провайдерм. Собственно, сегодня это распространенный пакет предлагаемый многими провайдерами для B2B.
и дуалстек получается тупиковая ветвь — возни больше, чем с чистым v4, а выхлопа вообще не видно.
...если не держать в голове, что DualStack это решение переходного периода и так или иначе исчезнет с переходом к чистому IPv6. Независимо от отношения к IPv6, переход на него неизбежен, потому как проблема исчерпания IPv4 никуда исчезнуть не может, а IPv6, помимо решения проблемы адресации, является более оптимальным с точки зрения сетевых техноглогий. Как именно реализовывать доступ для v4 - это второстепенный вопрос, ибо зависит от конкретных условий.
с динамическим префиксом-то? ну так себе…да и практика показала, что задачи «нужно чтобы все хосты локалки были доступны из инета» нет.
Динамическим - это двусмысленный термин. Префиксы должны назначаться статично, а вопрос доступа решается разными путями. Если ода префикса розданы хостам и оба доступны одновременно, то DNS можно резолвить в оба. Если динамическая замена - DynDNS. Может есть еще варианты, надо подумать.
Рассуждать о такой задаче в общем виде довольно бессмыслено, решения есть и другой вопрос - какое из них оптимально, но оптимальным оно может быть только под конкретную ситуацию и задачи.
вроде как теперь куда-то на учёт надо вставать, а то и СОРМ за свой счёт ставить…дальше, возьмём какой-нибудь магазин, основной канал через кабель, резервный — сотовый оператор, ему тоже свою AS получать? BGP настраивать? вы серьёзно?
Я, кстати, не знал про такой выверт российского законодательства. Но было бы странно, чтобы дизайнеры протокола учитывали непредсказуемость Фемиды в каждом отдельном государстве, с другой - да, выбирая оптимальное решение приходится брать такое в расчет.
Если же мы говорим про клиента как юрлицо, то большинство операторов могут предложить решение с предоставлением AS и пула, который может быть анонсирован через другого провайдера (даже при том, что выдаваемый пул входит в глобальный пул выдающего оператора). Тем более что крупные операторы обычно явдяются LIRами и могут зарегистрировать PI для клиента. Я не уверен, что клиент подпадает под требование установки СОРМ, так как не является саб-провайдером и не имеет нисходящих клиентов.
и как сделать в таком случае, например, «весь трафик в РФ идёт с префиксом A, а за границу — с префиксом B»? пихать таблицу маршрутизации с тысячами записей на все устройства в сети? что-то такое себе. а если просто балансировку между каналами делать?
На уровне хостов - никак. Собственно два PD это решение Active/Backup, оно не подразумевает специфичной логики маршрутизации или лоад-балансинга. Хотя последний может быть возможно реализовать посредством MP-TCP.
мне гораздо привычнее схема, когда маршрутизация задаётся на одном месте, на роутере
Мне тоже. Но дизайн IP подразумевает в этом случае либо отдельную AS и динамический роутинг с аплинками, либо шаманство в виде NAT, PBR и т.д.
именно. тут мы имеем трудозатраты по внедрению ipv6, но не получаем никаких плюсов. и да, чтобы всё работало нам ещё nat64/dns64 надо настроить. ибо ipv4-only сервера сплошь и рядом, а ipv6-only кроме ntc.party и не встречал
Трудозатраты относительно небольшие, по крайней мере те же по сравнению с подобной схемой с NAPT на IPv4. Но выгода все же есть. NPT66 не NAPT, нет манипуляции с портами, так что хосты внутри сети могут быть доступны извне, а значит главное преимущество IPv6 сохраняется.
nat64/dns64 - это при условии, что провайдерская сеть IPv6Only. Ежели она DualStack, то эта проблема отпадает. Но даже случай IPv6Only - это тоже не архисложно, но метод зависит от архитектуры провайдера.
Использование серых адресов сейчас, точнее последние 5 лет. Я собственно нигде это и нее отрицал. Но речь шла о десятилетиях использованя публичных статичных адресов IPv4 для ШПД.
Вы решили ткнуть меня носом в положение дел во Франции и ссылаетесть на сайт https://www.broadband.co.uk/ дающий обзор английских операторов? С вами все в порядке?
The four operators all have different IPv4 address sharing practices depending on their fixed network technologies:
- The majority of Free fixed network customers (75% in xDSL and 85% in FttH) as well as a small proportion of Bouygues Telecom customers (5% in xDSL and 2% in FttH) have a shared IPv4 address. However, these ISPs offer a dedicated IPv4 address free of charge on request.
- As of this year, some SFR customers also have a shared IPv4 address (8% in FttH) and this operator does not offer a dedicated IPv4 address on request for these customers.
- With regard to fixed 4G access, while Bouygues Telecom and SFR customers have a dedicated IPv4, Free and Orange customers have a shared IPv4 address.
These two ISPs do not offer dedicated IPv4 for fixed 4G.
- This sharing of IPv4 between several customers could become generalized in the coming years to face the shortage of IPv4.
И это при том, что отчет концентрируется именно на введении shared адресов операторами в последние годы, а не о практике существовавшей десятилетиями и приведшей к исчерпанию. Но вы же разбираетесь в теме, не так ли?
Использую на двух списаных ноутбуках Dell X1 20-летней давности в качестве переносных консолей для подключения к маршрутизаторам в датацентре. Нужны только эмулятор терминала и wireshark. Есть и современные ноуты, но Dell X1 во многом идеален и не хочу выкидывать из сентиментальных чувств. Прочие минималистичные дистрибутивы притормаживают, TinyCore летает.
Понравилась организация работы с приложениями, где каждое приложение монтируется как маленькая файловая система. Своеобразная контейниризация.
Ничего необычного в моем кейсе нет, но позволило продлить жизнь старому прекрасно работающему железу.
Интересно. Точнее интересная политика, хотя видимо подход как в штатах - либо аренда, либо свой собственный роутер. В Европе провайдер по умолчанию предоставляет свой роутер, это входит в абонемент. Хотя можно обойтись своим собственным оборудованием, но это исключительно гики, их доли процента. Потому вопросов совместимости не стоит ни у провайдера, ни у абонентов.
Конечно такой сервис как Youtube не станет просто так и себе в убыток отказываться от части своей аудитории и части своих доходов просто в угоду неким высоким идеям. Естественно во главе стоит здоровый прогматизм. Колличество просмотров (не важно через какой стек) конвертируется в колличество показов рекламы, а из показов - в финансовые доходы. Если принять гипотезу, что доля просмотров через IPv6 будет расти, а доля просмотров через IPv4 будет снижаться, то в какой-то момент последняя сравняется с расходами компании на поддержание этого стека (на лоадбалансеры, на CDN ящики, лицензии и т.д.) и в этот момент компания прекратит поддержку IPv4 (даже при том, что некая доля клиентов IPv4 еще останется). Или не прекратит, если посчитает, что имиджевые потери больше чем технические. Или прекратит раньше, посчитав, что поддержка единственного стека выгоднее в среднесрочной перспективе. Или если будет какое-то давление или наоборот - преференции со стороны регуляторов и политиков.
Я не думаю, что у нас с вами есть разночтения в этом плане.
В целом я полностью согласен с вашей оценкой. В действительности так и просходит и мы прошли через это - от IPv4Only, на DualStack (сейчас это 5/6 парка абонентов xDSL/FTTH), CGNAT чтобы выиграть время на разработку и тестирование MAP-T и наконец сам MAP-T. Коллекты (от доступа до BNG) DualStack, что позволяет иметь абонентов всех типов в общем коллекте и легко мигрировать из одного типа в другой. Например абонент которого не устраивает MAP-T имеет возможность переключиться обратно на DualStack (это менее 1% от мигрированных на MAP-T). Это решает в том числе проблему несовместимости CPE абонента. В ближайшее время вопрос отключения IPv4 в коллектах в планах не стоит, но в перспективе, с обновлением парка и/или миграцией подавляющего большинства абоенентов на IPv6 - не проблема. То есть в конечном итоге - да, когда-нибудь, предвидится.
Я единственное не понял, откуда 200-300 моделей роутеров? Имеются в виду CPE предоставляемые провайдером? У нас дай бог десяток моделей наберется, бОльший зоопарк провайдеру тянуть смысла нет. Пользовательские собственные CPE? Можно, но абонент либо поддерживает MAP-T, либо запрашивает возврат своей линии на DualStack и тогда использует стандартный набор параметров DHCPv4/v6.
Одно другого не исключает.
От ошибок и недочетов в дизайне и в реализации не застрахован никто. Но есть SPOF которые присутствуют изначально, они заложены в самой архитектуре. Например PON или телефонный коллектор не имеют резерва изначально, потеря OLT или DSLAM априори означают потерю всех подключенных к ним абонентов. В противоположенность им подсистема DNS всегда строится с избыточностью, но это не означает, что ошибка в скрипте не может гипотетически положить все сервера разом. Потому есть оценка надежности, есть вероятность отказа, есть методика использования схожих систем от разных производителей чтобы минимизировать риски, есть тесты BCP, есть "план B" для соблюдения SLA даже когда отказывает то, что не должно было отказать.
Это просто ориентировочные сроки, необходимые для развертывания IPv6 как такового. А дана ли команда на разворачивание, в каком обьеме, в каком ритме, с какими целями - это уже другой вопрос. Каждый провайдер здесь сам себе Буратино.
Да нет, вполне. Цикл плановой смены оборудования в среднем 5-10 лет, апгрейдов оборудования 4-7 лет (сильно зависит от роли оборудования), обновления софта - 2-3 года. На развертывание IPv6 с нуля (со всеми перечисленными пунктами) в среднем уйдет 1,5-2 года (если не форсировать). Если для развертывания требуются фичи, которые доступгы только в новых версиях и требуется обновление - развертывание обычно координируется с плановым обновлением. Это может сдвинуть время развертывания до 2-3 лет. Если требуется увеличение физической емкости - здесь зависит от конкретной ситуации, конкретного оборудования и его производителя, какого ресурса конкретно не хватает и оценки рисков и рынка. Может привести к дополнительной задержке, а может нет. В любом случае 3-4 года на разворачивание с нуля крупным провайдером это вполне рациональная оценка.
Плюс на это накладывается анализ рынка и планирование бюджета - обычно на 2 горизонта: на 3 года и на 5-6 лет вперед, что тоже кореллирует с оценкой развертывания.
То, что оборудование поддерживает IPv6, это не значит, что осталось пнуть рубильник и все заработает. Для оператора это:
Дизайн архитектуры, план адресации, написание HLD, LLD, ModOps
Тестирование конфигурации в testbed
Интеграция мониторинга в cockpit
интеграция с СОРМ
Интеграция в утилиты OSS (а то и дописывание утилит)
Обучение инженеров и команд эксплуатации
и многое другое, от маркетинга до поддержки
наконец сама конфигурация на роутерах разных уровней, BNG, MAP-T BR
допиливание софта для пользовательских CPE, со своими дизайном, спецификациями, тестированием
И это отдельно для бекбонов, агрегации, датацентров и т.д.
Это просто туннелирование, оно никоим образом не решает вопрос оперирования конечных устройств по новому протоколу и фактически означает не-переход на новый протокол.
Учитывая цикл обновления оборудования провайдерами и пересмотра архитектуры, я думаю, что в ближайшие 5 лет основной тренд будет в переводе публичных ресурсов на DualStack и предоставление IPv6 по умолчанию. Сама миграция (включая внутренние сети) - ближайшие 10-15 лет.
Включить пространство v4 в v6 это не проблема вообще. Проблема во всем прочем - нельзя было сделать обратную совместимость, даже просто увеличив поля под адреса в заголоке. Проблема не в IPv6, а в IPv4, последний не поддается модернизации.
Но опять же, решить только проблему нехватки адреса - это костыль, который не решал прочие врожденные недостатки IPv4. И когда стало ясно, что совместимости не будет даже при минимальных изменениях, то было решено создать новый протокол с нуля и заодно исправить недочеты предыдущего протокола. И это правильно.
Я бы не был столь категоричен. В частности в Индии существует программа перевода государственных сайтов c доступом IPv6Only
https://lafibre.info/images/logiciel/202503_gemini_test_ipv6_inde.pdf
И насколько я знаю, не только в Индии.
Спрос рождает предложение. Сейчас найти такие предложения не составит труда, все провайдеры работающие с сегментом B2B в состоянии предложить подобное решение. Тем более, что такие решения не тербуют капитальных затрат для провайдера, ни на оборудование, ни на архитектуру. Связка технологий дана для примера, это может быть FTTx+Mobile, FTTx+xDSL, FTTx+SAT и т.д. или в любых других комбинациях и технологиях. Даже для связки +Mobile не обязательно быть сотовым оператором, можно быть MVNO. B2B вообще гораздо более гибок в этом плане.
То, что два канала одного провайдера перестанут работать вместе очень низка, так как возможные SPOF могут быть только на уровне сетей доступа, а все что выше, начиная от агрегационных сетей и бекбона, имеет избыточность как минимум n+1. Сети наземного доступа и мобильного доступа (RAN) это физически раздельные сети (как минимум до уровня агрегации), а глобальный инцидент если и возможен, то провайдер имеет контрактное обязательство устранить неполадки в течении согласованного времени (SLA обычно 4 часа). Вот если гипотетический простой в 4 часа неприемлим для клиентского бизнеса, то подключаться к двум разным провайдерам имеет смысл.
Можно. Но это как из детской сказки - сколько можно сделать шапок из одной шкуры? 2 можно? Можно. А 3? Можно. А 5? Можно. Хоть 10, если не оговаривать размер получаемых шапок. Так и с IPv4. Можно выкручиваться, докупать адреса, ставить динамический CGNAT и начинать шарить каждый адрес на все большее и большее количество абонентов. Можно так делать? Конечно! Работать будет? Вполне. Некоторое время. Только доступный абонентам сервис будет все уже и уже. Доступ извне? Зачем? P2P сети? Ненужно. SIP телефония? Не скрепно. И т.д. Итог один : вместо поредоставления доступа в интернет, вы предоставляете некий доступ к некому сервису. "Доступ к VK и Госуслугам из дома", "чат с друзьями в MAX", "видео с Рутуба". Остальные пртоколы и сервисы вам не нужны, значит и нечего огрод городить. Тем более заморачиваться с IPv6 от которого ничего кроме головной боли. Мы как-то проглядели момент, когда временное и приносящее неудобства и ограничения решение NAT на IPv4 стало теплым и ламповым, а полноценная свобода доступа в инет стала пугающей и ненужной.
Кстати, цены на блоки IPv4 снижались, но похоже стабилизировались и начинают снова расти в цене. Есть много трактовок причин, суть в том, что это не принципиальное падение интереса к IPv6, а не более чем отсрочка в процессе перехода.
Да, верно. Надо будет изучить поподробнее.
Как интересно у вас мир перевернут.
Нет, конечно. Все же выриант с AS это тотальное решение, когда сеть должна иметь не только резервный канал, но еще и через независимого провайдера. В большинстве случаев для малых клиентов такое резервирование черезмерно, достаточно резервирования через два канала одного провайдера, но по разным технологиям - например FTTO + 4G/5G. В этом случае гараздо проще предоставить клиетну один и тот же PD через оба пути. Клиент защищен от сбоев в разных сетях доступа (Landed vs RAN), а там где общая часть провайдеской сети (бекбон, пиринги) - SLA контракта с провайдерм. Собственно, сегодня это распространенный пакет предлагаемый многими провайдерами для B2B.
...если не держать в голове, что DualStack это решение переходного периода и так или иначе исчезнет с переходом к чистому IPv6. Независимо от отношения к IPv6, переход на него неизбежен, потому как проблема исчерпания IPv4 никуда исчезнуть не может, а IPv6, помимо решения проблемы адресации, является более оптимальным с точки зрения сетевых техноглогий. Как именно реализовывать доступ для v4 - это второстепенный вопрос, ибо зависит от конкретных условий.
Динамическим - это двусмысленный термин. Префиксы должны назначаться статично, а вопрос доступа решается разными путями. Если ода префикса розданы хостам и оба доступны одновременно, то DNS можно резолвить в оба. Если динамическая замена - DynDNS. Может есть еще варианты, надо подумать.
Рассуждать о такой задаче в общем виде довольно бессмыслено, решения есть и другой вопрос - какое из них оптимально, но оптимальным оно может быть только под конкретную ситуацию и задачи.
Я, кстати, не знал про такой выверт российского законодательства. Но было бы странно, чтобы дизайнеры протокола учитывали непредсказуемость Фемиды в каждом отдельном государстве, с другой - да, выбирая оптимальное решение приходится брать такое в расчет.
Если же мы говорим про клиента как юрлицо, то большинство операторов могут предложить решение с предоставлением AS и пула, который может быть анонсирован через другого провайдера (даже при том, что выдаваемый пул входит в глобальный пул выдающего оператора). Тем более что крупные операторы обычно явдяются LIRами и могут зарегистрировать PI для клиента. Я не уверен, что клиент подпадает под требование установки СОРМ, так как не является саб-провайдером и не имеет нисходящих клиентов.
На уровне хостов - никак. Собственно два PD это решение Active/Backup, оно не подразумевает специфичной логики маршрутизации или лоад-балансинга. Хотя последний может быть возможно реализовать посредством MP-TCP.
Мне тоже. Но дизайн IP подразумевает в этом случае либо отдельную AS и динамический роутинг с аплинками, либо шаманство в виде NAT, PBR и т.д.
Трудозатраты относительно небольшие, по крайней мере те же по сравнению с подобной схемой с NAPT на IPv4. Но выгода все же есть. NPT66 не NAPT, нет манипуляции с портами, так что хосты внутри сети могут быть доступны извне, а значит главное преимущество IPv6 сохраняется.
nat64/dns64 - это при условии, что провайдерская сеть IPv6Only. Ежели она DualStack, то эта проблема отпадает. Но даже случай IPv6Only - это тоже не архисложно, но метод зависит от архитектуры провайдера.
Использование серых адресов сейчас, точнее последние 5 лет. Я собственно нигде это и нее отрицал. Но речь шла о десятилетиях использованя публичных статичных адресов IPv4 для ШПД.
Вы решили ткнуть меня носом в положение дел во Франции и ссылаетесть на сайт https://www.broadband.co.uk/ дающий обзор английских операторов? С вами все в порядке?
Вас не затруднит, если вы намерены спорить, хотя бы предварительно исследовать тему в первоисточниках? Или хотя бы взять адекватеный обзор? Я облегчу вам жизнь. Вот отчет ARCEP (французского регулятора) касательно всех четырех основных французских операторов - Orange, Free, Bouygues Telecom и SFR. https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arcep_2021_Barometer_of_the_Transition_to_IPv6.pdf
The four operators all have different IPv4 address sharing practices depending on their fixed network technologies:
- The majority of Free fixed network customers (75% in xDSL and 85% in FttH) as well as a small proportion of Bouygues Telecom customers (5% in xDSL and 2% in FttH) have a shared IPv4 address. However, these ISPs offer a dedicated IPv4 address free of charge on request.
- As of this year, some SFR customers also have a shared IPv4 address (8% in FttH) and this operator does not offer a dedicated IPv4 address on request for these customers.
- With regard to fixed 4G access, while Bouygues Telecom and SFR customers have a dedicated IPv4, Free and Orange customers have a shared IPv4 address.
These two ISPs do not offer dedicated IPv4 for fixed 4G.
- This sharing of IPv4 between several customers could become generalized in the coming years to face the shortage of IPv4.
И это при том, что отчет концентрируется именно на введении shared адресов операторами в последние годы, а не о практике существовавшей десятилетиями и приведшей к исчерпанию. Но вы же разбираетесь в теме, не так ли?