Конечно. Хотя боюсь, что если не вдаваться в подробности обсуждения деталей конкретных функций, то получится банальный список преимуществ с которых начинается любая книга по IPv6. Но тем не менее: стройный и оптимизированный для обработки сетевым оборудованием формат заголовка; механизм расширяемости заголовка, что позволяет развивать протокол и адаптировать под принципиально новые цели (пример - SRv6); многотиповая адресация, включающая обязательную локальную адресацию, что вместе с автоконфигурированием SLAAC (причем как базовая часть самого протокола) решает вопрос автономной работы сегмента сети, изначальное сосуществование различных префиксов на одном интерфнйсе дает значительную гибкость архитектуры; философия резделения префикса и интерфейсной части адреса где интерфейсная часть предусматривает избыточное колличество адресов в подсети, позволяет избежать пререадресации подсети из-за нехватки адресов; изначальная четкая административная иерархия адресов, что позволяет качественно агрегировать маршруты в таблице маршрутизации и тем снизить их общее число, а следовательно снизить время конвергенции; почти полное избежание фрагментации, что положительно сказывается на производительности и проч. проч. проч. ...завершая сегментной маршрутизацией SRv6, которая заменяет костыль MPLS и упрощает программирование путей (traffic engineering), что, с учетом упрощения стека протоколов управления сетью, выглядит эффективнее SR/MPLS и тем более RSVP-TE, а с другой стороны дает новые возможности маршрутизации согласно различным критериям (network slicing).
Нельзя сказать, что каждое из перечисленных преимуществ является уникальным и/или революционным именно благодаря IPv6. Большинство из них имеют в том или ином виде реализацию в существующем IPv4 / MPLS. Изящество IPv6 заключается в том, что лучшие идеи и решения, наработанные за последние полвека, складываются в единую стройную систему, которая тем не менее оставляет возможность дальнейшей эволюции протокола без костылей и патовых ситуаций обратной несовместимости. С определенной точки зрения, IPv6 это работа над ошибками и переосмысление всего опыта построения сетей.
Это в общем виде. А далее, если говорить о изяществе, то стоит обсуждать конкретные решения/функции/фичи в частности.
Микрософт вообще убрал в W10/W11 возможность добавлять пользовательские панели в таскбар, что просто бесит, особенно если вы привыкли пользоваться ими в течении десятилетий. Подобная программа решает именно эту проблему.
Не совсем понимаю откуда берется "на порядок". На бумаге все корректно, но это было справедливо четверть века назад, в эпоху коаксиала и хабов. С тотальным распространением коммутаторов и микросегментации (когда в сегменте находятся только сам коммутатор и единственный хост, к тому же работающие в дуплексе) говорить о конкуренции доступа к передаче - бессмысленно. Пропускная будет зависить от тактовой частоты, алгоритма модуляции, межкадровых интервалов. Но откуда отимизация на порядок? Или я что-то упустил?
Однако это не меняет сути дискуссии. На мой взгляд, повторюсь, черезмерная интеграция разных функций в одной программе (особенно при остутствии модульности) является плохой практикой, приводящей к ожирению продукта со всеми вытекающими последствиями - неэффективному использованию рессурсов, к усложнению продукта, к ухудшению процесса разработки и поддержки. Но это я уже формулировал выше.
Мне кажется вы ошибаетесь. Bloatware - это всякий дополнительный софт, устанавливаемый вместе с основной программой, часто без согласия пользователя. Зачастую эти программы вообще мало соотносились с основной. Как "книга в нагрузку", в советские времена. Мы же говорим о программах, которые стали включать внутрь себя кучу фич, которые не связаны напрямую с изначальным назначением основной программы.
Около 25% пользователей Opera Presto использовало встроенный почтовый клиент. Так что это очень большая доля.
Позвольте с вами не согласиться. На тот момент уровень оптимизации приложений был выше нежели сегодня. По причине меньших обьемов пвмяти, меньшей мощности процессоров, меньшего уровня промежуточных абстракций API.
Базовый уровень был приемлим для большинства пользователей? Прекрасно. Только для дускуссии было бы хорошо если бы вы привели статистику доли от этих пользователей, которые использовали эти дополнительные функции Оперы, в частности почтовый клиент. У меня такой статистики нет, но есть сомнения, что встроеный почтовый клиент был так же широко востребован как сам навигатор. Именно из-за скудности его функционала по сравнению с повсеместно используемыми в России TheBat'ом и Outlook'ом. Именно это могло бы быть аргументом в дискусии комбинированных решений против набора отдельных специализированных приложений.
Но ключевое опущение в вашей аргументации это "на тот момент". То, что Опера 7 реализовывала насколько функций как таковых не говорит о том, что эти функции были реализованы на приемлимом уровне (по сравнению с реализациями тех же функций в отдельных приложениях), но тем более не говорит о том, что такое комбинирование является эффективным решением на сегодняшний день - именно как единая среда для большинства каждодневно используемых приложений (включая помимно навигатора почтовый клиент, мессенджеры, текстовый редактор, графический редактор, ssh клиент и проч. - у каждого свой собственный список). Реализовать базовый набор функций не сложно, все проблемы начинаются вместе с нюансами, когда к функции появляются специфичные требования. В этом плане отдельные приложения в состоянии предоставить эти специфичные возможности, комбинированные приложения - нет. А если и пытаются охватить специфичные требования, то быстро монстроизируются. К тому же, замедляется реакция разработчиков на развитие таких комбайнов - требуется охватывать изменения в гораздо более широком списке областей, с отдельной проблематикой в каждой области. Хорошо если успевают латать дыры, а дожидаться новых или специфичных функций можно годами. Разработчики приложения для отдельной области куда более оперативны и гараздо лучше владеют своей темой.
Разумеется, комбинированные решения тоже имеют свою нишу и востребованы. Я использовал ту же Оперу как портабельный тулкит в поездках. Но речь идет не о конкретном приложении, а именно о самом подходе как таковом и единственный (пусть даже удачный) пример не является достаточной аргументацией. Outlook тоже комбайн, но большинство своих функций он выполняет очень плохо.
Не очень понял ваш довод. Размер файлов браузера это один из параметров, причем один из самых незначительных. Скорее вопрос как он обходился с памятью, с ресурсами CPU и мультипоточностью, что у него с правами и ограничением доступа к файлам на диске, к камере, к usb? Не говоря уже о том, насколько этот гигантский функционал был реально функционален, и не являлся свистелками и перделками (по сравнению с отдельными решениями каждой из фич на тот момент)? И как-то странно говорить про решение эффективное 20 лет назад с точки зрения технологий и требований сегодняшнего дня. OS/2 тоже была прекрасна 30 лет назад, но как-то странно ее сравнивать с сегодняшними ОС и теми задачами которые они решают.
"Уважаемые пассажиры! Добро пожаловать на борт нашего нового авиалайнера. На первом этаже расположены салон, боулинг и ресторан, на втором этаже - библиотека, бар и джакузи, на третьем - солярий и поле для минигольфа.
А теперь просим занять свои места и мы попробуем взлететь со всей этой херней."
А если серьезно, то я согласен с предыдущим оратором. Как показывает история, попытка впихнуть все в единую среду всегда приводит к монстроидальности и тяжеловесности. Уже проходили с джавой и различными методами виртуализации, направленными на абстрагирования от уровня OS и железа. Преимущества были (и остаются) очевидными - кросплатформенность, стандартизация среды разработки и выполнения, и т.д. и т.п., но... мировой революции так и не произошло. Потому что у всякой палки всегда находится другой конец, такой как проблемы производительности, проблемы оптимального использования ресурсов, проблемы управления доступом к ресурсам и проч.
В этом плане UNIX-way мне импонирует куда больше. Под каждую задачу - свой инструмент. Колоть орехи микроскопом можно, но лучше все же взять орехоколку.
...и вся красота заканчивается в момент разворачивания IPv6. Когда выясняется, что OSPFv2 не поддерживает IPv6 и надо параллельно разворачивать OSPFv3. Не переходить с одного на другой, а именно разворачивать параллельно, ибо обновленный OSPFv3 не в состоянии поддерживать 2 семейства адресов в рамках одного процесса, так что придется поднимать либо OSPFv2+OSPFv3, либо 2хOSPFv3 (один для IPv4, другой - для IPv6).
В действительности просветление часто настуавет раньше, с переходом на IS-IS.
Использую на двух списаных ноутбуках 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. Но тем не менее: стройный и оптимизированный для обработки сетевым оборудованием формат заголовка; механизм расширяемости заголовка, что позволяет развивать протокол и адаптировать под принципиально новые цели (пример - SRv6); многотиповая адресация, включающая обязательную локальную адресацию, что вместе с автоконфигурированием SLAAC (причем как базовая часть самого протокола) решает вопрос автономной работы сегмента сети, изначальное сосуществование различных префиксов на одном интерфнйсе дает значительную гибкость архитектуры; философия резделения префикса и интерфейсной части адреса где интерфейсная часть предусматривает избыточное колличество адресов в подсети, позволяет избежать пререадресации подсети из-за нехватки адресов; изначальная четкая административная иерархия адресов, что позволяет качественно агрегировать маршруты в таблице маршрутизации и тем снизить их общее число, а следовательно снизить время конвергенции; почти полное избежание фрагментации, что положительно сказывается на производительности и проч. проч. проч. ...завершая сегментной маршрутизацией SRv6, которая заменяет костыль MPLS и упрощает программирование путей (traffic engineering), что, с учетом упрощения стека протоколов управления сетью, выглядит эффективнее SR/MPLS и тем более RSVP-TE, а с другой стороны дает новые возможности маршрутизации согласно различным критериям (network slicing).
Нельзя сказать, что каждое из перечисленных преимуществ является уникальным и/или революционным именно благодаря IPv6. Большинство из них имеют в том или ином виде реализацию в существующем IPv4 / MPLS. Изящество IPv6 заключается в том, что лучшие идеи и решения, наработанные за последние полвека, складываются в единую стройную систему, которая тем не менее оставляет возможность дальнейшей эволюции протокола без костылей и патовых ситуаций обратной несовместимости. С определенной точки зрения, IPv6 это работа над ошибками и переосмысление всего опыта построения сетей.
Это в общем виде. А далее, если говорить о изяществе, то стоит обсуждать конкретные решения/функции/фичи в частности.
Микрософт вообще убрал в W10/W11 возможность добавлять пользовательские панели в таскбар, что просто бесит, особенно если вы привыкли пользоваться ими в течении десятилетий. Подобная программа решает именно эту проблему.
Я пользуюсь другой - TrayToolbar'ом https://github.com/brondavies/TrayToolbar/, он полегче, портабельный.
Не совсем понимаю откуда берется "на порядок". На бумаге все корректно, но это было справедливо четверть века назад, в эпоху коаксиала и хабов. С тотальным распространением коммутаторов и микросегментации (когда в сегменте находятся только сам коммутатор и единственный хост, к тому же работающие в дуплексе) говорить о конкуренции доступа к передаче - бессмысленно. Пропускная будет зависить от тактовой частоты, алгоритма модуляции, межкадровых интервалов. Но откуда отимизация на порядок? Или я что-то упустил?
Вы продолжаете пользоваться встроенным в вивальди почтовым клиентом?
Принято
У меня нет причин не верить вам на слово.
Однако это не меняет сути дискуссии. На мой взгляд, повторюсь, черезмерная интеграция разных функций в одной программе (особенно при остутствии модульности) является плохой практикой, приводящей к ожирению продукта со всеми вытекающими последствиями - неэффективному использованию рессурсов, к усложнению продукта, к ухудшению процесса разработки и поддержки. Но это я уже формулировал выше.
Мне кажется вы ошибаетесь. Bloatware - это всякий дополнительный софт, устанавливаемый вместе с основной программой, часто без согласия пользователя. Зачастую эти программы вообще мало соотносились с основной. Как "книга в нагрузку", в советские времена. Мы же говорим о программах, которые стали включать внутрь себя кучу фич, которые не связаны напрямую с изначальным назначением основной программы.
Любопытно. Это ваша оценка или есть источник?
Позвольте с вами не согласиться. На тот момент уровень оптимизации приложений был выше нежели сегодня. По причине меньших обьемов пвмяти, меньшей мощности процессоров, меньшего уровня промежуточных абстракций API.
Базовый уровень был приемлим для большинства пользователей? Прекрасно. Только для дускуссии было бы хорошо если бы вы привели статистику доли от этих пользователей, которые использовали эти дополнительные функции Оперы, в частности почтовый клиент. У меня такой статистики нет, но есть сомнения, что встроеный почтовый клиент был так же широко востребован как сам навигатор. Именно из-за скудности его функционала по сравнению с повсеместно используемыми в России TheBat'ом и Outlook'ом. Именно это могло бы быть аргументом в дискусии комбинированных решений против набора отдельных специализированных приложений.
Но ключевое опущение в вашей аргументации это "на тот момент". То, что Опера 7 реализовывала насколько функций как таковых не говорит о том, что эти функции были реализованы на приемлимом уровне (по сравнению с реализациями тех же функций в отдельных приложениях), но тем более не говорит о том, что такое комбинирование является эффективным решением на сегодняшний день - именно как единая среда для большинства каждодневно используемых приложений (включая помимно навигатора почтовый клиент, мессенджеры, текстовый редактор, графический редактор, ssh клиент и проч. - у каждого свой собственный список). Реализовать базовый набор функций не сложно, все проблемы начинаются вместе с нюансами, когда к функции появляются специфичные требования. В этом плане отдельные приложения в состоянии предоставить эти специфичные возможности, комбинированные приложения - нет. А если и пытаются охватить специфичные требования, то быстро монстроизируются. К тому же, замедляется реакция разработчиков на развитие таких комбайнов - требуется охватывать изменения в гораздо более широком списке областей, с отдельной проблематикой в каждой области. Хорошо если успевают латать дыры, а дожидаться новых или специфичных функций можно годами. Разработчики приложения для отдельной области куда более оперативны и гараздо лучше владеют своей темой.
Разумеется, комбинированные решения тоже имеют свою нишу и востребованы. Я использовал ту же Оперу как портабельный тулкит в поездках. Но речь идет не о конкретном приложении, а именно о самом подходе как таковом и единственный (пусть даже удачный) пример не является достаточной аргументацией. Outlook тоже комбайн, но большинство своих функций он выполняет очень плохо.
Не очень понял ваш довод. Размер файлов браузера это один из параметров, причем один из самых незначительных. Скорее вопрос как он обходился с памятью, с ресурсами CPU и мультипоточностью, что у него с правами и ограничением доступа к файлам на диске, к камере, к usb? Не говоря уже о том, насколько этот гигантский функционал был реально функционален, и не являлся свистелками и перделками (по сравнению с отдельными решениями каждой из фич на тот момент)? И как-то странно говорить про решение эффективное 20 лет назад с точки зрения технологий и требований сегодняшнего дня. OS/2 тоже была прекрасна 30 лет назад, но как-то странно ее сравнивать с сегодняшними ОС и теми задачами которые они решают.
"Уважаемые пассажиры! Добро пожаловать на борт нашего нового авиалайнера. На первом этаже расположены салон, боулинг и ресторан, на втором этаже - библиотека, бар и джакузи, на третьем - солярий и поле для минигольфа.
А теперь просим занять свои места и мы попробуем взлететь со всей этой херней."
А если серьезно, то я согласен с предыдущим оратором. Как показывает история, попытка впихнуть все в единую среду всегда приводит к монстроидальности и тяжеловесности. Уже проходили с джавой и различными методами виртуализации, направленными на абстрагирования от уровня OS и железа. Преимущества были (и остаются) очевидными - кросплатформенность, стандартизация среды разработки и выполнения, и т.д. и т.п., но... мировой революции так и не произошло. Потому что у всякой палки всегда находится другой конец, такой как проблемы производительности, проблемы оптимального использования ресурсов, проблемы управления доступом к ресурсам и проч.
В этом плане UNIX-way мне импонирует куда больше. Под каждую задачу - свой инструмент. Колоть орехи микроскопом можно, но лучше все же взять орехоколку.
...и вся красота заканчивается в момент разворачивания IPv6. Когда выясняется, что OSPFv2 не поддерживает IPv6 и надо параллельно разворачивать OSPFv3. Не переходить с одного на другой, а именно разворачивать параллельно, ибо обновленный OSPFv3 не в состоянии поддерживать 2 семейства адресов в рамках одного процесса, так что придется поднимать либо OSPFv2+OSPFv3, либо 2хOSPFv3 (один для IPv4, другой - для IPv6).
В действительности просветление часто настуавет раньше, с переходом на IS-IS.
Использую на двух списаных ноутбуках 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, со своими дизайном, спецификациями, тестированием
И это отдельно для бекбонов, агрегации, датацентров и т.д.