Что поделать... это проблемы роста. Они пройдут. Даже 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.
Так что то, что вы можете получить в реальности напрямую зависит от того, что и как провайдер способен вам предоставить.
И да и нет. Конкретная конфигурация зависит от конкретного прозводителя - Cisco, Nokia, Huawei, Microtik, Linux, Windows - следует смотреть документацию. Хотя при разном синтаксисе все они оперируют одними у теми же понятиями и принципами и понимая эти принципы и протоколы, не составляет труда создать нужную конфигурацию. В сети полно туториалов для конфигурировании того или иного устройства. Куда важнее это понимание самих принципов.
Из литературы я могу порекомендовать "IPv6 Fundamentals" - by Rick Graziani - 2ed (CiscoPress, 2017). Самая лучшая из всех книг что я видел по основам IPv6, как по материалу, так и по изложению.
Есть несколько книг от O'Reilly, например "IPv6 Essentials" - by Silvia Hagen 3ed - O'Reilly, 2014, но после "IPv6 Fundamentals" она уже вторична.
По планированию адресации есть "IPv6 Address Planning" - by Tom Coffeen - O'Reilly, 2014.
По DNS - "DNS and BIND on IPv6" - by Cricket Liu - O'Reilly, 2011 (хотя несколько устарела)
Все эти книги можно найти в электронном виде в рунете :)
"IPv6 для знатоков IPv4", Ярослав Тихий - 2013, https://maxim.int.ru/stuff/ipv6_ru.pdf несколько скомкана, но дает много для понимания базы и философии IPv6. Рекомендую в дополнение к "IPv6 Fundamentals".
Разумеется есть многое, что пришло в IPv6 в последние годы (виртуализация, IPv6 в датацентрах, в сетях предприятий, SRv6 и т.д.), но это уже специализированные вещи.
возможно , торможение внедрения ipv6 связанно именно с боязнью появления анонимных, не убиваемых распределеных платформ
Торможение внедрения IPv6 связанно исключительно с масштабностью необходимых изменений в сети без явной краткосрочной отдачи, на обновление програмного обеспечения, если оно разработано самой компанией и работает многие годы (первый закон "работает - не трогай" никто не отменял). Но в первую очередь все упирается в затраты на обучение персонала и острой нехватке сетевых дизайнеров, способных организовать переход компании на IPv6. IPv6 это фундаментальное изменение, которое необходимо делать планомерно и постепенно, а не в режиме аврала. Потому вызывает у менеджмента опасения и откладывается до лучших времен.
Ботнет это следствие дыр в прошивках и операционках устройств и халатности в настройке файерволов. Никакого прямого отношения к тому или иному стеку это не имеет. Ботнеты и черви появились до развертывания IPv6.
Так и IPv4 предназначен машинам, а не людям. :) Для читаемости IPv4 к нему был быстро придуман DNS.
Просто когда разрабатывали IPv4, люди работали куда ближе к железу - скорость в 300 бод была вполне значительной, коды непрямую содержали как отображаемые символы, так и управляющие коды, а дебагер представлял собой стальную раскладушку, куда вставлялась перфолента и через матрицу отверстий можно было пробить недостающие дырки.
То, что IPv4 недокрутили, чтобы совсем спрятать под капот - на то есть много причин. Это не значит, что не хотели, даже пытались исправить недостатки всякими "костылями". IPv6 позволил избежать этих недостатков и с самого начала проектировался с механизмами автоконфигурации. Так что для конечного пользователя большой разницы нет.
Как нет ее и для профессионалов, так как нет принципильной разницы в работе с IPv4 и IPv6. IPAM адоптировался, команды роутеров, утилиты отладки, интерфейсы систем управления, SDN - тоже. Ничего в сущности не поменялось. Нужно чуть времени чтобы привыкнуть.
Если буквально, то вы правы. Но контекст немного иной. ARCEP форсировал внедрение IPv6 чтобы выровнять внедрение между операторами. Смотрите годовой очет ARCEP по переходу на IPv6: https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arcep_Barometre_2024_de_la_transition_vers_IPv6.pdf глава 2.1.2. По состоянию на середину 2019 (когда принималось решение n° 2019-1386), Bouygues Telecom уже имел 55% мобильных абонентов с доступом по IPv6. SFR и Orange уже несколько лет готовились в запуску IPv6 и выход этого решения удивительным образом совпал с их готовностью - Orange c середины 2019, SFR - с середины 2020.
Официальная мотивация регулятора - "Обязательство поддерживать IPv6 для обеспечения совместимости сервисов и предотвращения препятствий в использовании сервисов, доступных только по IPv6, в условиях растущего числа терминалов и нехватки адресов IPv4 в RIPE NCC". В реальности, для конечных абонентов - предоставить равные условия при выборе или переходе от оператора к оператору, для операторов - давить на четвертого оператора Free, на которого у других операторов есть зуб за демпинговый выход Free на мобильный рынок в 2012 году.
Короче, там своя политика и мотивация у всех участников, но для конечных абонентов и для распространения IPv6 это было благом.
И да и нет. Минусов IPv6 дает не больше чем IPv4, недостатки скорей связаны с отставанием в реализации IPv6 в домашнем оборудовании и в домашних маршрутизаторах, что не в последнюю очередь перекликается с отсутствием устоявшегося опыта провайдеров в оргинизации сетей доступа IPv6 для конечных абонентов. В плане тех же файерволов - никакой принципиальной разницы между IPv4 и IPv6 в этом плане нет.
А вот потенцильных плюсов - масса. Если суметь ими воспользоваться.
Как развивать инфру внутри предприятия - есть наработанные гидлайны и методики, все зависит от предприятия, его бизнеса, архитектуры сети. Основная проблема не техническая, а в обучении и переквалификации персонала, потому что главная проблема - копирование образа мышления IPv4 на IPv6.
До сих пор нормальной работы DHCPv6 нет, а все разговоры про ND как лучший метод распределения адресов из предоставленного префикса - разбиваются после вопросов о контроле адресов и настройках доступов.
Простите, а где и в чем нет "нормальной работы DHCPv6"? И в чем проблема с ND? ND не занимается распределением адресов, а если вы говорите про SLAAC, то он прекрасно работает как для LLA, и для назначения GUA адресов особенно в тупиковой сети, где контроль адресов не нужен (например в домашней сети).
Для сетей с необходимостью контроля, DHCPv6 работает вполне эффективно, а недостающая в частных случаях функциональность постепенно покрывается развитием пртокола (например RFC9686)
Позвольте полюбопытствовать, откуда такая информация об "обязательствах"? Я о такой не в курсе. Есть общая стратегия недрения IPv6 в мобильных и фиксированных сетях, она всячески привеетствуется ARCEP, но никак не является обязательной. Необходимость IPv6 продиктована технической необходимостью у самих операторов и провайдеров.
Использование NAT откладывает проблему, но не решает ее. Так или иначе, ресурс IPv4 исчерпан, активная экономия этих адресов (через динамическое назначение и разделение адреса между несколькими клиентами, централизированный CGNAT) усложняет сети, сужает возможности для конечного потребителя и тормозит развитие сетей в целом.
Не стоит связывать замедление распространения IPv6 в последние 10 лет с вновь "вдруг открывшимся потенциалом IPv4". Причина замедления в перекосе абонентского трафика в сторону операторов контента, CDN и крупных соцсетей - что сильно упростило маршрутизацию до 2-3 AS в пути и сильно сократило список успользуемых протоколов.
Прирост эффективности IPv6 по сравнению с IPv4 - 12-20% (по данным исследования Гугла) - за счет исчезновения NAT, отсутствия фрагментации и оптимизации ASIC под IPv6 заголовок. При переходе на IPv6-only, экономия на ресурсах BNG, упрощение архитектуры коллектов и OSS, снижение затрат на разработку софта для клиентских CPE. Для провайдеров - более эффективная маршрутизация на SRv6. Для хостеров - адресация на уровне приложений и контейнеров и опять-таки - программируемая маршрутизация end-to-end благодаря тому же SRv6. IoT, для которого IPv4 тесен. Прибыль от IPv6 есть, все зависит от грамотности его внедрения.
В США и Европе предлагается IPv6 либо в DualStack, либо IPv6-only, но с поддержкой MAP-T, таким образом IPv4 для вас остается доступен до тех пор, пока он вам нужен, но является теперь опциональным сервисом. Стоит говорить про покрытие IPv6 на уровне 60-99% в этих странах и форсирование перевода государственных сайтов и служб на IPv6?
При сегментации и стагнации Интернета, IPv6 будет востребован всё меньше и меньше
Сильно заблуждаетесь. На данный момент только провайдеры и операторы занимаются внедрением IPv6 в своих сетях, и то, только для доступа клиентов и маршрутизации их трафика v6. Миграция внутренних сетей даже не планируется. А у предприятий вне непосредственно области IT - банков, заводов, страховых компаний - IPv6 вообще не предвидится. Ибо из отсутствия понятной выгоды от перехода на другой стек и вообще понятного смысла (не считая уже затрат на внедрение, модернизацию сети и затрат на обучение персонала). Потому роль государства в плане популяризации IPv6 очень важна. Например во Франции этим занимается регулятор ARCEP, мониторит развитие IPv6 в стране, устраивает конференции для популяризации IPv6, выпускает гиды для обьяснения "зачем" и "как" внедрять IPv6 для предприятий. https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6.html
Например, если есть N серверов, смотрящих наружу через 1 балансировщик, то можно сэкономить айпишники, выставив наружу 1 v4 адрес, а внутри подняв связность через v6.
Я вам другой интересный кейс подкину. Некая компания предоставляет сервис VOD и для распределения нагрузки между серверами была вынуждена использовать дорогостоящие балансировщики. Нашли весьма изящное альтернативное решение - назначили каждому видеофайлу на серверах отдельный IPv6 адрес (собственно хватило одной /64 подсети на всю видеотеку) и таким образом автоматически распределили нагрузку между каналами используя ECMP, то есть используя базовые механизмы IP маршрутизации. Балансировщики убрали за ненадобностью.
Во‑вторых, есть ULA‑адреса, fd00::/8, они применяются для настройки соединения через туннели.Можно создать туннель, и присвоить ему такие адреса для обмена по ipv6, вместо или вместе с ipv4
Можно присвоить ULA адреса для туннеля. Но не нужно. ULA адреса вообще про другое. Они используются так же как GUA адреса, но когда нужно чтобы адесованная таким образом сеть однозначно не была доступна извне. Например сеть лаборатории, завода, внутренняя сеть оборудования и и.д. ULA похожа на приватную сеть IPv4 RFC1918, но не предназначена для трансляции в GUA адреса.
Для point-to-point туннеля ни GUA, ни ULA адресация не нужна, для маршрутизации все равно будет использоваться LLA, кроме как если необходимо чтобы интерфейс вашего IPv6 роутера в подсети туннеля был доступен извне, например для пинга.
Ну, могу сделать еще один ipv6-only сайт с картинкой и лозунгом «Давайте все!» — но те, кто его достанет через ipv6 — и так уже в ipv6, а остальным оно недоступно и не надо.
Это называется "проблема Уроборос v6". Нет ресурсов v6, потому нет пользователей v6, а раз нет пользователей v6, то нет смысла создавать ресурсы v6. Заколдованный круг, для которого на одном из v6-day было предложено шуточное решение: открыть сайты с бесплатным порно, но доступным только по v6. :)
И тут то же самое: вроде хорошо, вроде интересно — но что это сейчас дает, кроме излишней прозрачности?Какие практические преимущества с точки зрения использования?
Дает много чего, это тема для отдельной статьи. Для обычного пользователя прирост производительности сети до 20% (реально 5-10%) за счет убирания NAT, оптимизации маршрутизации в провайдерских сетях, а так же более эффектвной работе с пакетами v6 магистральным сетевым оборудованием. Для провайдеров и операторов - очень эффективная маршрутизация SRv6. Интересные возможности для датацентров и решений виртуализации и контейнеризации. В плане развития интернета - большие возможности для IoT и для развития пиринговых сетей. Продолжать можно долго.
Сложно ответить без конкретики, на то что вам не нравятся в той части обязанностей, которые не приносят желаемого удовлетворения.
Ну так я и не ищу конкретных ответов, это же не частная консультация. Наоборот, это обобщение, видимо для подходу к неким общим рецептам, которые можно лишь прочитать, примерить на себя, согласиться либо нет, и если да - попытаться применить. Лично мне ваше обобщение кажется необоснованным (хотя допускаю, для кого-то или каких-то частных случаев, ваше обоснование может оказаться вполне справедливым), так как, на мой взгляд, вы пытаетесь весьма сложную тему свести к весьма упрощенной схеме.
Поймите меня правильно, это не критика ради критики. Я предпочту дождаться вашей третьей статьи и уже затем оценить ее возможную пользу.
Да, медсестры выполняют очень тяжелую работу и эта работа плохо оплачивается. Причем это характерно для любых стран, даже для богатых. Во Франции и Англии медработники регулярно бастуют, требуя улучшения условий труда. Но мотивация для каждой сестры исключительно персональная. Для одних это личное чувство долга, для других это радость от выздоровления, для третьих - стаж и первый этап в медицинской карьере, для четвертых - религиозные ценности, и т.д. Проведите опрос среди медсестер в хосписе или в доме престарелых. Я не берусь сказать, что является для них мотивацией, и насколько сама трудность работы является демотиватором для каждой из них. Потому я считаю этот пример еще более неадекватным, чем с победителями лотереи.
Да, моя работа приносит мне удовольствие. Я занимаюсь именно тем, чем мечтал заниматься. Но в мою работу, помимо всего прочего, входят обязанности, которые мне в тягость и которыми я не хотел бы заниматься. Не имеет значени процентное соотношение прятного и неприятного, ибо если значение приятного перевешивает значение неприятного, то нет никакого смысла менять работу в целом. А это значит, что придется как-то выполнять неприятные обязаности тоже и вопрос прокрастинации связан именно с этой неприятной частью работы. При том, что в моем случае, эти неприятные обязанности невозможно компенсировать какими-то далеко поставленными целями (например, карьерным ростом), ради которых их стоит терпепть. Потому что перетерпев и достигнув более высокого поста, вы обнаружите, что кроме желанных преимуществ новый пост тоже содержит неприятные обязанности. Только другие.
И это еще не затронуты другие причины прокрастинации (помимо неприятных обязанностей), такие как перфекционизм.
Вы обьяснили два механизма стимулов. Логично. Подкрепили результатами эксперимента. Не очень логично, потому, как верно отметил комментатор выше, выиграть 50К и 1М - это две большие разницы, ибо вопрос не в сумме, а в возможности в корне изменить свою жизнь (что, кстати, можно сделать и без денег, но с деньгами проще). Правда размер выборки респондентов ставит под сомнение результаты этого "эксперимента" в принципе. К тому же куда более широкая статистика распоряжения большими выигрышами говорит о несостоятельности мечты - множество счастливчиков спустило и прокрутило гигантский выигрыш буквально за считанные дни. Хотя может для кого яркая и краткая вспышка предельного счастья прожигания удачи была достаточна для удовлетворения до конца жизни, несмотря на то, что пришлось вернуться на старые рельсы. Из всего этого "эксперимента" вы сделали вывод к тому, что не надо идти к мечте и цели, а нужно ценить маленькие жизненные радости. Ибо у самурая нет цели, а есть только путь. Но если жизненных радостей нет - то надо валить нахрен. Ценный совет. Несомненно. Хотя такой глубинной мысли читать умные статьи не требуется. Это крайность. А большинство людей работает на вполне любимой работе, но даже на самой любимой работе есть задачи приятные и неприятные и проблема прокрастинации заключается именно в том, как преодолеть и мотивировать себя на решение этой неприятной части работы. Но вот про методы борьбы конкретно с прокрастинацией я, если не ошибаюсь, не прочитал в статье ни-че-го. Вы уверены, что если заглянуть в ваш телеграм-канал, то там откроются сокровища сокровенного и полезного знания по данной теме?
France Telecom выдавал минители бесплатно, в довесок к медной паре и телефонному номеру. То есть терминал стоял приктически в каждом доме. Было удобно, например я помню как проверял возможные задержки рейса, прежде чем ехать в аэропорт.
Отчасти минитель был причиной медленного старта интернета во Франции.
То что вы этого не видели, это не значит что этого нет. :) Чаще всего провайдеры используют динамический CGNAT, не подразумевающий вообще входящие соединания для пользователя, соответственно уведомлять пользователя не о чем. Если же вы реализуете архитектуру с фиксированным пулом портов для пользователя, то пользователь должен его знать. В нашем случае нет необходимости сообщать CPE назначеный ему пул портов, он его знает по последним битам полученного приватного IP адреса (механизм описан в указанном мною драфте), а свой публичный адрес используемый на CGNAT - через опцию 125 DHCPv4. Использовать только предоставляемый нами CPE не обязательно, эта логика AFAIK поддерживается OpenWRT. Можно вообще обойтись без этой логики, если ваш CPE (или ваш комп с напрямую воткнутым патчордом) позволяет задать пул портов для трансляции вручную. Все исходящие соединения, которые использует порты не входящие в ваш пул просто не пройдут CGNAT. Так же, чисто для информации, ваш публичный IPv4 адрес и пул портов указаны в вашем кабинете на портале провайдера.
Я не видел провайдеров позволяющих доступ исключительно со своих CPE, хотя, судя по обсуждениям на форумах, такие есть. Чаще всего вы может заменить провайдерский CPE на свой, хотя при этом скорее всего потеряете такие фичи как телефонию и TVoIP. Ну и разумеется в случае DSL ваш CPE должен иметь (или вы должны иметь внешний ) модем, а в случае FTTH ваш провайдер должен предлагать отдельный ONT (а не только CPE с инетгрированным ONT).
Если даже решать эту проблему, получится слишком специфично у каждого провайдера, общедоступную технологию на этом не построишь.
Ну тут либо шашечки, либо ехать. Чудес не бывает, даже если найти решение. Так что согласен. Аминь.
А ну понятно, двухуровневая схема. Я про такие даже не слышал.
Простите, а какую схему вы видели? Пользователю в лучшем случае выдают 1 публичный IPv4 адрес для CPE, а не подсеть для LAN. Так что у пользователя NAPT как минимум есть, на его CPE. А если выдают приватный, чтобы потом странслировать его на CGNAT, то суть точно та же. Ну а так как мы изначально говорим про CGNAT, то вот вам вторая точка трансляции.
Это же не корпоративная сеть, где пользователи в общей сети и нужеен только один адресный транслятор на границе.
1:8, хотя в теории могло быть плотнее, зато нагрузка выносится с центральной железки на много железок моменьше.
1:8 - это результат анализа нашей собственной статистики. Даже у озабоченных гиков суммарное количество открытых соединений не превышает двух тысяч, у большинства обычных пользователей - пара сотен. Так что 8К портов на пользователя - это с запасом.
Это для фиксированного доступа. Для мобильного CGNAT 1:128 или 1:256. С учетом, что 99,9% мобильных пользователей это единственный терминал (смартофон), то 256 портов более чем хватает. Или 512.
На множестве маленьких железок у нас реализован MAP-T. Я не знаю, общая ли это ситуация или наш частный случай, но CGNAT был взят на мощном железе и стоил сильно дорого, хотя это возможно из-за кастомной логики реализующей упомянутый мной драфт. Его имело смысл централизовать, а не децентрализовывать, как MAP-T. Хотя и MAP-T, IMHO, лучше централизовать и размещать как можно ближе к пирингу, но это выбор архитекторов конкрентной сети согласно конкретным условиям.
Видеоконфа на число участников > 2 требует центральный сервер
Для большинства пользователей нужны point2ponint звонки, а не видеоконференции.
атомизировать пользователей и жёстко завязать их на свои сервера
Зачем? Наоборот! Выгодней разгрузить свои сервера, пусть пользователи сами, на своем же железе, раздают выложеные нами файлы. Всем выгода - компании нагрузка меньше, пользователю - распространение быстрее, а доступность раздаваемых файлов - выше. А еще можно самому себе проблем создать. Мне помнится как на заре iPhon'ов Apple выложил апдейт и весь мир ломанулся апгрейдиться однвременно, положив сервера Apple похлеще DDoS атаки.
Бизнес на обьеме трафика уже много лет как нет, разве что у Tier 1 провайдеров, да и то, если они ошибаюсь, они за BW берут, а не за прокаченный трафик. Так что компании в первую очередь интересно избежать наплыва пользователей и лишнего трафика.
Будут сидеть в своих p2p-сетках, IRC-чатиках (что важно - немодерируемых, а потому более привлекательных.
Некая малая часть несомненно будет, но по сравнению с аудиторией FB, VK и иже сними - это так, в размере погрешности. Основная масса не найдет в этих p2p-сетках и IRC-чатиках ни котиков, ни "лайкни, чтобы посмотреть сколько нас" и "99% людей на смогли решить 2+2x2". Большинство не слезет с дофаминовых лент ради независимого общения в чатах формата 20+-летней давности. Я тоже ностальгирую по news конференциям и фидо, но эта эпоха уже ушла.
Что поделать... это проблемы роста. Они пройдут. Даже 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.
Так что то, что вы можете получить в реальности напрямую зависит от того, что и как провайдер способен вам предоставить.
И да и нет. Конкретная конфигурация зависит от конкретного прозводителя - Cisco, Nokia, Huawei, Microtik, Linux, Windows - следует смотреть документацию. Хотя при разном синтаксисе все они оперируют одними у теми же понятиями и принципами и понимая эти принципы и протоколы, не составляет труда создать нужную конфигурацию. В сети полно туториалов для конфигурировании того или иного устройства. Куда важнее это понимание самих принципов.
Из литературы я могу порекомендовать "IPv6 Fundamentals" - by Rick Graziani - 2ed (CiscoPress, 2017). Самая лучшая из всех книг что я видел по основам IPv6, как по материалу, так и по изложению.
Есть несколько книг от O'Reilly, например "IPv6 Essentials" - by Silvia Hagen 3ed - O'Reilly, 2014, но после "IPv6 Fundamentals" она уже вторична.
По планированию адресации есть "IPv6 Address Planning" - by Tom Coffeen - O'Reilly, 2014.
По DNS - "DNS and BIND on IPv6" - by Cricket Liu - O'Reilly, 2011 (хотя несколько устарела)
Все эти книги можно найти в электронном виде в рунете :)
"IPv6 для знатоков IPv4", Ярослав Тихий - 2013, https://maxim.int.ru/stuff/ipv6_ru.pdf несколько скомкана, но дает много для понимания базы и философии IPv6. Рекомендую в дополнение к "IPv6 Fundamentals".
Разумеется есть многое, что пришло в IPv6 в последние годы (виртуализация, IPv6 в датацентрах, в сетях предприятий, SRv6 и т.д.), но это уже специализированные вещи.
Торможение внедрения IPv6 связанно исключительно с масштабностью необходимых изменений в сети без явной краткосрочной отдачи, на обновление програмного обеспечения, если оно разработано самой компанией и работает многие годы (первый закон "работает - не трогай" никто не отменял). Но в первую очередь все упирается в затраты на обучение персонала и острой нехватке сетевых дизайнеров, способных организовать переход компании на IPv6. IPv6 это фундаментальное изменение, которое необходимо делать планомерно и постепенно, а не в режиме аврала. Потому вызывает у менеджмента опасения и откладывается до лучших времен.
Ботнет это следствие дыр в прошивках и операционках устройств и халатности в настройке файерволов. Никакого прямого отношения к тому или иному стеку это не имеет. Ботнеты и черви появились до развертывания IPv6.
Так и IPv4 предназначен машинам, а не людям. :) Для читаемости IPv4 к нему был быстро придуман DNS.
Просто когда разрабатывали IPv4, люди работали куда ближе к железу - скорость в 300 бод была вполне значительной, коды непрямую содержали как отображаемые символы, так и управляющие коды, а дебагер представлял собой стальную раскладушку, куда вставлялась перфолента и через матрицу отверстий можно было пробить недостающие дырки.
То, что IPv4 недокрутили, чтобы совсем спрятать под капот - на то есть много причин. Это не значит, что не хотели, даже пытались исправить недостатки всякими "костылями". IPv6 позволил избежать этих недостатков и с самого начала проектировался с механизмами автоконфигурации. Так что для конечного пользователя большой разницы нет.
Как нет ее и для профессионалов, так как нет принципильной разницы в работе с IPv4 и IPv6. IPAM адоптировался, команды роутеров, утилиты отладки, интерфейсы систем управления, SDN - тоже. Ничего в сущности не поменялось. Нужно чуть времени чтобы привыкнуть.
Если буквально, то вы правы. Но контекст немного иной. ARCEP форсировал внедрение IPv6 чтобы выровнять внедрение между операторами. Смотрите годовой очет ARCEP по переходу на IPv6: https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arcep_Barometre_2024_de_la_transition_vers_IPv6.pdf глава 2.1.2. По состоянию на середину 2019 (когда принималось решение n° 2019-1386), Bouygues Telecom уже имел 55% мобильных абонентов с доступом по IPv6. SFR и Orange уже несколько лет готовились в запуску IPv6 и выход этого решения удивительным образом совпал с их готовностью - Orange c середины 2019, SFR - с середины 2020.
Официальная мотивация регулятора - "Обязательство поддерживать IPv6 для обеспечения совместимости сервисов и предотвращения препятствий в использовании сервисов, доступных только по IPv6, в условиях растущего числа терминалов и нехватки адресов IPv4 в RIPE NCC". В реальности, для конечных абонентов - предоставить равные условия при выборе или переходе от оператора к оператору, для операторов - давить на четвертого оператора Free, на которого у других операторов есть зуб за демпинговый выход Free на мобильный рынок в 2012 году.
Короче, там своя политика и мотивация у всех участников, но для конечных абонентов и для распространения IPv6 это было благом.
И да и нет. Минусов IPv6 дает не больше чем IPv4, недостатки скорей связаны с отставанием в реализации IPv6 в домашнем оборудовании и в домашних маршрутизаторах, что не в последнюю очередь перекликается с отсутствием устоявшегося опыта провайдеров в оргинизации сетей доступа IPv6 для конечных абонентов. В плане тех же файерволов - никакой принципиальной разницы между IPv4 и IPv6 в этом плане нет.
А вот потенцильных плюсов - масса. Если суметь ими воспользоваться.
Как развивать инфру внутри предприятия - есть наработанные гидлайны и методики, все зависит от предприятия, его бизнеса, архитектуры сети. Основная проблема не техническая, а в обучении и переквалификации персонала, потому что главная проблема - копирование образа мышления IPv4 на IPv6.
Простите, а где и в чем нет "нормальной работы DHCPv6"? И в чем проблема с ND? ND не занимается распределением адресов, а если вы говорите про SLAAC, то он прекрасно работает как для LLA, и для назначения GUA адресов особенно в тупиковой сети, где контроль адресов не нужен (например в домашней сети).
Для сетей с необходимостью контроля, DHCPv6 работает вполне эффективно, а недостающая в частных случаях функциональность постепенно покрывается развитием пртокола (например RFC9686)
Позвольте полюбопытствовать, откуда такая информация об "обязательствах"? Я о такой не в курсе. Есть общая стратегия недрения IPv6 в мобильных и фиксированных сетях, она всячески привеетствуется ARCEP, но никак не является обязательной. Необходимость IPv6 продиктована технической необходимостью у самих операторов и провайдеров.
Использование NAT откладывает проблему, но не решает ее. Так или иначе, ресурс IPv4 исчерпан, активная экономия этих адресов (через динамическое назначение и разделение адреса между несколькими клиентами, централизированный CGNAT) усложняет сети, сужает возможности для конечного потребителя и тормозит развитие сетей в целом.
Не стоит связывать замедление распространения IPv6 в последние 10 лет с вновь "вдруг открывшимся потенциалом IPv4". Причина замедления в перекосе абонентского трафика в сторону операторов контента, CDN и крупных соцсетей - что сильно упростило маршрутизацию до 2-3 AS в пути и сильно сократило список успользуемых протоколов.
Прирост эффективности IPv6 по сравнению с IPv4 - 12-20% (по данным исследования Гугла) - за счет исчезновения NAT, отсутствия фрагментации и оптимизации ASIC под IPv6 заголовок. При переходе на IPv6-only, экономия на ресурсах BNG, упрощение архитектуры коллектов и OSS, снижение затрат на разработку софта для клиентских CPE. Для провайдеров - более эффективная маршрутизация на SRv6. Для хостеров - адресация на уровне приложений и контейнеров и опять-таки - программируемая маршрутизация end-to-end благодаря тому же SRv6. IoT, для которого IPv4 тесен. Прибыль от IPv6 есть, все зависит от грамотности его внедрения.
В США и Европе предлагается IPv6 либо в DualStack, либо IPv6-only, но с поддержкой MAP-T, таким образом IPv4 для вас остается доступен до тех пор, пока он вам нужен, но является теперь опциональным сервисом. Стоит говорить про покрытие IPv6 на уровне 60-99% в этих странах и форсирование перевода государственных сайтов и служб на IPv6?
Вы явно не в теме.
Сильно заблуждаетесь. На данный момент только провайдеры и операторы занимаются внедрением IPv6 в своих сетях, и то, только для доступа клиентов и маршрутизации их трафика v6. Миграция внутренних сетей даже не планируется. А у предприятий вне непосредственно области IT - банков, заводов, страховых компаний - IPv6 вообще не предвидится. Ибо из отсутствия понятной выгоды от перехода на другой стек и вообще понятного смысла (не считая уже затрат на внедрение, модернизацию сети и затрат на обучение персонала). Потому роль государства в плане популяризации IPv6 очень важна. Например во Франции этим занимается регулятор ARCEP, мониторит развитие IPv6 в стране, устраивает конференции для популяризации IPv6, выпускает гиды для обьяснения "зачем" и "как" внедрять IPv6 для предприятий. https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6.html
Я вам другой интересный кейс подкину. Некая компания предоставляет сервис VOD и для распределения нагрузки между серверами была вынуждена использовать дорогостоящие балансировщики. Нашли весьма изящное альтернативное решение - назначили каждому видеофайлу на серверах отдельный IPv6 адрес (собственно хватило одной /64 подсети на всю видеотеку) и таким образом автоматически распределили нагрузку между каналами используя ECMP, то есть используя базовые механизмы IP маршрутизации. Балансировщики убрали за ненадобностью.
Можно присвоить ULA адреса для туннеля. Но не нужно. ULA адреса вообще про другое. Они используются так же как GUA адреса, но когда нужно чтобы адесованная таким образом сеть однозначно не была доступна извне. Например сеть лаборатории, завода, внутренняя сеть оборудования и и.д. ULA похожа на приватную сеть IPv4 RFC1918, но не предназначена для трансляции в GUA адреса.
Для point-to-point туннеля ни GUA, ни ULA адресация не нужна, для маршрутизации все равно будет использоваться LLA, кроме как если необходимо чтобы интерфейс вашего IPv6 роутера в подсети туннеля был доступен извне, например для пинга.
Это называется "проблема Уроборос v6". Нет ресурсов v6, потому нет пользователей v6, а раз нет пользователей v6, то нет смысла создавать ресурсы v6. Заколдованный круг, для которого на одном из v6-day было предложено шуточное решение: открыть сайты с бесплатным порно, но доступным только по v6. :)
Дает много чего, это тема для отдельной статьи. Для обычного пользователя прирост производительности сети до 20% (реально 5-10%) за счет убирания NAT, оптимизации маршрутизации в провайдерских сетях, а так же более эффектвной работе с пакетами v6 магистральным сетевым оборудованием. Для провайдеров и операторов - очень эффективная маршрутизация SRv6. Интересные возможности для датацентров и решений виртуализации и контейнеризации. В плане развития интернета - большие возможности для IoT и для развития пиринговых сетей. Продолжать можно долго.
Ну так я и не ищу конкретных ответов, это же не частная консультация. Наоборот, это обобщение, видимо для подходу к неким общим рецептам, которые можно лишь прочитать, примерить на себя, согласиться либо нет, и если да - попытаться применить. Лично мне ваше обобщение кажется необоснованным (хотя допускаю, для кого-то или каких-то частных случаев, ваше обоснование может оказаться вполне справедливым), так как, на мой взгляд, вы пытаетесь весьма сложную тему свести к весьма упрощенной схеме.
Поймите меня правильно, это не критика ради критики. Я предпочту дождаться вашей третьей статьи и уже затем оценить ее возможную пользу.
Да, медсестры выполняют очень тяжелую работу и эта работа плохо оплачивается. Причем это характерно для любых стран, даже для богатых. Во Франции и Англии медработники регулярно бастуют, требуя улучшения условий труда. Но мотивация для каждой сестры исключительно персональная. Для одних это личное чувство долга, для других это радость от выздоровления, для третьих - стаж и первый этап в медицинской карьере, для четвертых - религиозные ценности, и т.д. Проведите опрос среди медсестер в хосписе или в доме престарелых. Я не берусь сказать, что является для них мотивацией, и насколько сама трудность работы является демотиватором для каждой из них. Потому я считаю этот пример еще более неадекватным, чем с победителями лотереи.
Да, моя работа приносит мне удовольствие. Я занимаюсь именно тем, чем мечтал заниматься. Но в мою работу, помимо всего прочего, входят обязанности, которые мне в тягость и которыми я не хотел бы заниматься. Не имеет значени процентное соотношение прятного и неприятного, ибо если значение приятного перевешивает значение неприятного, то нет никакого смысла менять работу в целом. А это значит, что придется как-то выполнять неприятные обязаности тоже и вопрос прокрастинации связан именно с этой неприятной частью работы. При том, что в моем случае, эти неприятные обязанности невозможно компенсировать какими-то далеко поставленными целями (например, карьерным ростом), ради которых их стоит терпепть. Потому что перетерпев и достигнув более высокого поста, вы обнаружите, что кроме желанных преимуществ новый пост тоже содержит неприятные обязанности. Только другие.
И это еще не затронуты другие причины прокрастинации (помимо неприятных обязанностей), такие как перфекционизм.
Вы обьяснили два механизма стимулов. Логично. Подкрепили результатами эксперимента. Не очень логично, потому, как верно отметил комментатор выше, выиграть 50К и 1М - это две большие разницы, ибо вопрос не в сумме, а в возможности в корне изменить свою жизнь (что, кстати, можно сделать и без денег, но с деньгами проще). Правда размер выборки респондентов ставит под сомнение результаты этого "эксперимента" в принципе. К тому же куда более широкая статистика распоряжения большими выигрышами говорит о несостоятельности мечты - множество счастливчиков спустило и прокрутило гигантский выигрыш буквально за считанные дни. Хотя может для кого яркая и краткая вспышка предельного счастья прожигания удачи была достаточна для удовлетворения до конца жизни, несмотря на то, что пришлось вернуться на старые рельсы. Из всего этого "эксперимента" вы сделали вывод к тому, что не надо идти к мечте и цели, а нужно ценить маленькие жизненные радости. Ибо у самурая нет цели, а есть только путь. Но если жизненных радостей нет - то надо валить нахрен. Ценный совет. Несомненно. Хотя такой глубинной мысли читать умные статьи не требуется. Это крайность. А большинство людей работает на вполне любимой работе, но даже на самой любимой работе есть задачи приятные и неприятные и проблема прокрастинации заключается именно в том, как преодолеть и мотивировать себя на решение этой неприятной части работы. Но вот про методы борьбы конкретно с прокрастинацией я, если не ошибаюсь, не прочитал в статье ни-че-го. Вы уверены, что если заглянуть в ваш телеграм-канал, то там откроются сокровища сокровенного и полезного знания по данной теме?
France Telecom выдавал минители бесплатно, в довесок к медной паре и телефонному номеру. То есть терминал стоял приктически в каждом доме. Было удобно, например я помню как проверял возможные задержки рейса, прежде чем ехать в аэропорт.
Отчасти минитель был причиной медленного старта интернета во Франции.
Так вроде размер продиктован размером стандартной клетки на карте.
А из какого пластика печатали?
То что вы этого не видели, это не значит что этого нет. :) Чаще всего провайдеры используют динамический CGNAT, не подразумевающий вообще входящие соединания для пользователя, соответственно уведомлять пользователя не о чем. Если же вы реализуете архитектуру с фиксированным пулом портов для пользователя, то пользователь должен его знать. В нашем случае нет необходимости сообщать CPE назначеный ему пул портов, он его знает по последним битам полученного приватного IP адреса (механизм описан в указанном мною драфте), а свой публичный адрес используемый на CGNAT - через опцию 125 DHCPv4. Использовать только предоставляемый нами CPE не обязательно, эта логика AFAIK поддерживается OpenWRT. Можно вообще обойтись без этой логики, если ваш CPE (или ваш комп с напрямую воткнутым патчордом) позволяет задать пул портов для трансляции вручную. Все исходящие соединения, которые использует порты не входящие в ваш пул просто не пройдут CGNAT. Так же, чисто для информации, ваш публичный IPv4 адрес и пул портов указаны в вашем кабинете на портале провайдера.
Я не видел провайдеров позволяющих доступ исключительно со своих CPE, хотя, судя по обсуждениям на форумах, такие есть. Чаще всего вы может заменить провайдерский CPE на свой, хотя при этом скорее всего потеряете такие фичи как телефонию и TVoIP. Ну и разумеется в случае DSL ваш CPE должен иметь (или вы должны иметь внешний ) модем, а в случае FTTH ваш провайдер должен предлагать отдельный ONT (а не только CPE с инетгрированным ONT).
Ну тут либо шашечки, либо ехать. Чудес не бывает, даже если найти решение. Так что согласен. Аминь.
Простите, а какую схему вы видели? Пользователю в лучшем случае выдают 1 публичный IPv4 адрес для CPE, а не подсеть для LAN. Так что у пользователя NAPT как минимум есть, на его CPE. А если выдают приватный, чтобы потом странслировать его на CGNAT, то суть точно та же. Ну а так как мы изначально говорим про CGNAT, то вот вам вторая точка трансляции.
Это же не корпоративная сеть, где пользователи в общей сети и нужеен только один адресный транслятор на границе.
1:8 - это результат анализа нашей собственной статистики. Даже у озабоченных гиков суммарное количество открытых соединений не превышает двух тысяч, у большинства обычных пользователей - пара сотен. Так что 8К портов на пользователя - это с запасом.
Это для фиксированного доступа. Для мобильного CGNAT 1:128 или 1:256. С учетом, что 99,9% мобильных пользователей это единственный терминал (смартофон), то 256 портов более чем хватает. Или 512.
На множестве маленьких железок у нас реализован MAP-T. Я не знаю, общая ли это ситуация или наш частный случай, но CGNAT был взят на мощном железе и стоил сильно дорого, хотя это возможно из-за кастомной логики реализующей упомянутый мной драфт. Его имело смысл централизовать, а не децентрализовывать, как MAP-T. Хотя и MAP-T, IMHO, лучше централизовать и размещать как можно ближе к пирингу, но это выбор архитекторов конкрентной сети согласно конкретным условиям.
Для большинства пользователей нужны point2ponint звонки, а не видеоконференции.
Зачем? Наоборот! Выгодней разгрузить свои сервера, пусть пользователи сами, на своем же железе, раздают выложеные нами файлы. Всем выгода - компании нагрузка меньше, пользователю - распространение быстрее, а доступность раздаваемых файлов - выше. А еще можно самому себе проблем создать. Мне помнится как на заре iPhon'ов Apple выложил апдейт и весь мир ломанулся апгрейдиться однвременно, положив сервера Apple похлеще DDoS атаки.
Бизнес на обьеме трафика уже много лет как нет, разве что у Tier 1 провайдеров, да и то, если они ошибаюсь, они за BW берут, а не за прокаченный трафик. Так что компании в первую очередь интересно избежать наплыва пользователей и лишнего трафика.
Некая малая часть несомненно будет, но по сравнению с аудиторией FB, VK и иже сними - это так, в размере погрешности. Основная масса не найдет в этих p2p-сетках и IRC-чатиках ни котиков, ни "лайкни, чтобы посмотреть сколько нас" и "99% людей на смогли решить 2+2x2". Большинство не слезет с дофаминовых лент ради независимого общения в чатах формата 20+-летней давности. Я тоже ностальгирую по news конференциям и фидо, но эта эпоха уже ушла.