Потребуются весьма нетривиальные доказательства, что в таком случае жертвой насилия является именно Гитлер. Причём, после того, как он это "заслужил", так сказать. И доказательства убедительные, а не просто сказки о распятых мальчиках.
Ок, замените ваш пример на
Я не собираюсь тут заниматься словесным жонглированием. Мне достаточно и того, что поступки однозначно предосудительные, вне зависимости ни от чего — существуют.
И высокомерная в придачу.
Только с точки зрения трусов, которых обижает наличие своих принципов у других людей.
И да. Почему вы говорите "трусость" так, как будто это что-то плохое?
Опять же, те люди, в чьей этической системе трусость не является плохим качеством, не имеют права осуждать тех, у кого есть своя позиция и принципы.
Потому, что есть категория конфликтов, не оставляющая пространства для личной трусости.
Например, жертва-насильник. Тут не может быть серой морали, жертва не должна учитывать интересы насильника, тут нет места виктимблеймингу, поиску поводов и оправданий, кто кого куда спровоцировал и т.п.
Поэтому ответ на вопрос "осуждаете ли вы половое насилие" -- это да или нет. Оба они честны, хотя и полярны этически. А ответ "я просто хочу быть человеком" -- это личная трусость.
То, что изъятие из списка мэйнтейнеров является наказанием -- далеко не очевидно. Может это действительно мера безопасности, и приплетать тут зиппенхафт как-то не алё.
Я не знаю, что вы называете "хайдингом", но я имел в виду RFC 8981
Вы как-нибудь уж определитесь с точки зрения ИБ, а то разницы между датчиком температуры в вашей квартире и датчиком на вышке разницы нольцелых-нольдесятых
Определяюсь -- датчик температуры в квартире не является критическим оборудованием, не участвует в производственных процессах и выход его из строя не несёт ущерба. Поэтому он может торчать голой жопой в интернет, а ваши свитчи и всё, что под ними -- не могут.
Мы уже обсуждаем настройку файрволлов на двух устройствах - граничном МЭ и устройстве, а в ipv4+nat достаточно только МЭ
Где обсуждаем? С ipv6 файрволл на устройстве тоже не нужен, если он настроен на МЭ, где его настройка полностью аналогична v4.
Это вы решили что его там почему-то быть не может, а я собирал систему на 300+ датчиков разбросанных по площади в 20 км² угадайте, через что они передавали данные.
Нет смысла угадывать. Вы могли там каждому датчику хоть по Старлинку или Иридиуму выдать, откуда я знаю? Спектр возможных вариантов тут очень широк -- от банальных EDGE модулей до какого-нибудь AFSK поверх ISM радио.
Какое всё это отношение имеет к простоте деплоя IPv6 в сетях?
Ну и в целом тогда персонализированный вопрос - сколько систем АСУ\IoT\АСКУЭ вы запроектировали и собрали, что так бодро рассуждаете о том что ipv6 там не нужно?
Допустим, одну. Или две, смотря как считать. А что? Ad hominem чешется? :)
Именно, это убивает одно из ключевых решений ipv6 по разгрузке сетей за счет p2p-соединений (тех же ВКС, торренты и пр.)
IPv6 всё-таки разрабатывался, чтобы решить проблему исчерпания адресного пространства.
То, что он потенциально может вернуть Инету его изначальную идеологию p2p это, конечно, хорошо, но мы, кажется, уже плотно в эпохе облаков живём, и p2p нужен только гикам.
Если мы хотим пользоваться фичей и таки разгрузить сети, то надо заниматься свистопляской с ACL, портами, группами и пр.
Трудозатраты, еще раз я говорю не про конкретные решения, а про то что IPv6 требует телодвижений, любое телодвижение это время = деньгам.
А я говорю о том, что телодвижений там будет или меньше, чем с IPv4, или ровно столько же.
Давать. И она даст на все и сразу.
А можно посмотреть, как выглядит "на всё и сразу"?
Если правило отключить, то все устройства становятся доступны
В том-то и дело, что не становятся. И телепатия тут не нужна, вы просто игнорируете огромного слона в маленькой комнате -- вам почему-то кажется, что все устройства, получившие в вашей сети белый IPv6 тут же полезут наружу и будут кричать "ау, я здесь" всем подряд потенциальным злоумышленникам. Но это не так.
Вы в курсе о рекомендуемых практиках выделения IPv6 диапазонов?
Что будет с ESP32 если ее начать DoS-ить?
Чтобы начать что-то досить, его сначала нужно найти.
Давайте промавтоматика сама определит должна она ходить в интернет или не должна?
Давайте. Но тогда ваш довод не работает, так как вы аргументируете отсутствием поддержки того, чего в целевых сценариях применения там быть не может.
Вы просили пример оборудования из 2024 года которое не работает с IPv6 - получите, оно существует, оно работает, закупается и поставляется.
Хорошо, вы меня убедили. Действительно, нишевому оборудованию, которое по принятым практикам сетевой безопасности вообще в интернет нельзя пускать (ну или как минимум через пограничный файрволл) IPv6 не нужен и его там справедливо нет.
В следующий раз буду явно уточнять, что я имею в виду маршрутизаторы.
Например мой домашний ПК c dev-сервером под win 10\11 (на самом деле home-lab). Сейчас за NAT'ом я не парюсь - открыты порты\закрыты, пофигу. Приходит в дом ipv6 и вот что? я должен пойти и прописать разные правила - на уровне, allow incoming ipv6 from LAN; deny incoming all from ipv6; ок, а потом окажется, что создавая встречу условного zoom ко мне не могут подключиться и понеслось - сиди разбирайся какое приложение нужно, какое нет.
Вы или выдумываете проблему на ровном месте, или ваша последняя винда была в районе ХР.
В этом конкретном случае файрволл, встроенный в винду, разберётся за вас. И да, он по умолчанию запрещает всё, что не разрешено явно, даже пинги. А запрос на явное разрешение вылазит как только какая-то прикладная прога запрашивает листенинг на публичном интерфейсе. Тут же создаётся разрешающее правило для неё и всё работает. Для продвинутого софта я не поленился и поднял UPnP на пограничном роутере -- и тогда ещё более всё работает. От прихода IPv6 ничего в этой схеме принципиально не меняется.
А с чего его не будет если правила не прикручены?
Я не просто так задал этот вопрос — он с подвохом. Подумайте ещё раз. Как вы представляете себе получение доступа к устройствам внутри сети клиента, начиная с их обнаружения.
Вы прокручиваете те же самые аргументы, которые тут уже прокручивали до вас десятки раз под комментами в десятках подобных статей.
время на настройку firewall на конечных устройствах
Это каких, например? Если встроенный firewall на устройстве не имеет заранее заданного разумного дефолта, то настраивать его придётся для обоих версий, что займёт примерно одинаковое количество времени. Если же он имеет разумный дефолт для v4, то его скопировать для v6 -- тривиальная задача.
время на настройку граничного fw - актуально для iot. Т.к. сейчас за nat'ом к железу нет доступа по умолчанию, то с ipv6 надо добавлять в ACL
А с чего вы взяли, что без nat'а к устройствам iot на ipv6 будет доступ по умолчанию?
время на модернизацию старого оборудования (не все прошивки esp8211(или как он там)/esp32 поддерживают ipv6
Во-первых,
В ESP32 IPv6 поддерживается вендором через вполне себе официальный ESP-IDF, который умеет в dual stack.
У ESP8266 незрелость поддержки v6 -- это исключительно и только вопрос желания вендора. Туда не добавляют какие-то фишки разве что потому, что он считается low-end устройством по сравнению с ESP32.
Во-вторых, модернизировать их, по большому счёту, нет необходимости. Есть же NAT64 и другие решения.
время на обучение, тестирование и проверку корректности настроек( это кстати ооочень прилично времени займет)
Почему это займёт времени больше, чем всё то же самое для IPv4 ? IPv6 существенно умнее в плане автоматической настройки.
в целом я и коммутаторы могу найти в_продаже_ без ipv6)
Найдите, пожалуйста. Очень хочу посмотреть на эту аномалию.
Всё правильно - телефоны сканируют эфир при потере сигнала и ничего не излучают. Кстати, именно поэтому батарея у телефона разряжается быстрее при потере сигнала, т.к. приёмник включён постоянно. Если же сигнал есть, то в режиме ожидания телефон включает приёмник только в определённые периоды (paging group), тем самым экономя заряд.
Извините, но то что вы тут написали -- это чушь.
Излучение радиоволн, как активная операция -- требует от телефона намного большей мощности (порядка 500-2000 миливатт), чем пассивное прослушивание эфира в режиме приёмника (около 10-50 миливатт).
Приёмник и так включён постоянно, не зависимо от того, есть сигнал базовой станции или нет. Если бы приёмник не был включён постоянно, базовая станция не могла бы его вызвать в любую секунду.
Paging group это не про отключение приёмника, это про рассылку бродкаста группе находящихся рядом терминалов в данной и в соседних ячейках, так как терминалы имеют свойство перемещаться в пространстве, и так их легче найти.
Если бы телефон постоянно что-то излучал при потере сигнала - то это было бы косвенно заметно по его нагреву, но этого не происходит.
Это противоречит вашим же словам о том, что батарея разряжается быстрее. Так как нагревается она от повышенного тока, и, следовательно, мощности.
как критически возрастает количество излучения, когда в метро поезд въезжает в тоннель, где отсутствует сотовая связь, и сотовые телефоны, даже находящиеся в режиме ожидания, начинают активно искать базовую станцию.
Какая-то ерунда написана. телефоны излучают только когда "слышат" базовую станцию и им надо ей что-то сообщить -- инициировать вызов, отправить сообщение, зарегистрироваться и т.п. Если станцию не слышно, они молчат и просто сканируют диапазон частот в поисках чего-нибудь.
В качестве небольшого отступления: именно на этом проекте я весьма объёмно осознал, что частота и передача данных очень тесно взаимосвязаны. Скажу честно, я раньше об этом не задумывался, просто воспринимал как некие абстрактные цифры, глубоко не задумываясь над физическим смыслом.
Это просто Вы никак не изучите общепринятое определение обсуждаемого термина.
Теорию я знаю, но не могу избавиться от ощущения что вы как-то уж слишком буквально ставите телегу формальных метрик впереди кодовой лошади. Впрочем, дело вкуса.
Но половина кода написанного в таком стиле будет содержать в 2 раза меньше багов чем весь такой код - так что принцип продолжает работать.
Но и писать такой код никто не будет, потому что это дольше, дороже, и бизнесу непонятно зачем нужно.
Проблема в том, что это пока не включено, и неизвестно когда будет и будет ли вообще включено
Будет. Как только IPv6 реально пойдёт в массы и станет востребован среди целевой аудитории, дистро-строители озаботятся более-менее безопасными дефолтами.
Почти весь IoT и прочие стиральные машины с пылесосами и холодильниками обычно на линухе,
Очень оптимистичная оценка. Современный линух не так-то просто впихнуть в рамки типичного же современного IoT устройства. Малинообразные устройства так и не стали индустриальным стандартом, как для IoT так и вообще, так что там либо какая-нибудь экзотика типа VxWorks, либо винегрет из embedded OS, у которых стек tcp/ip не из линуха.
все роутеры, "свистки" для телевизоров… ну и заметный процент десктопов тоже.
не все роутеры (есть роутеры на том же VxWorks), а процент десктопов незаметный.
Можете дать ссылки на исследования по этому вопросу, или это ваше личное ощущение?
Это мой личный опыт, скажем так, шапки, которая в годы молодости не всегда была белой.
Целевые атаки (именно на пен, а не тупой ддос) чрезвычайно редки. Целевые атаки на пен на клиентскую сторону -- чрезвычайно редки в квадрате. Все последние легендарные успехи на этом поприще -- фишинг, трояны в почте и социалка. Вы поинтересуйтесь, как спецслужбы вкорячивали Stuxnet иранцам — через виндовый autorun, ага.
И домножьте это на долю юзеров, которые ходят в инет с белых адресов сейчас и вам тоже это станет очевидно.
Лезть внутрь локалки IPv4 прикрытой NAT-ом было явно не проще и не дешевле. Но в IPv6 это может изменится.
А может и не измениться. Вы этого не знаете заранее, а я вижу, что разработчики IPv6 на эту тему думали и предлагали решения, тот же RFC 8981.
но пока он не заменяет старый код а добавляется к нему - добавляются и его уязвимости. Если раньше можно было атаковать только код в стеке IPv4, то теперь можно атаковать и его, и код в стеке IPv6 - следовательно поверхность атаки увеличилась.
Это какая-то очень эзотерическая логика. Чем меньше кода, тем больше его защищённость, серьёзно? Ну ок, давайте повыкидываем обработку эксепшнов, канареек из стэка выбросим, санитайзеры всякие, zerofill-аллокации, сборщики мусора, вот это всё. Сразу защищённее станет, ага.
Но по факту - он таки более уязвим (хоть в данном контексте это и не важно). Просто потому, что он более новый и он менее активно используется - а в таких условиях в коде всегда больше ошибок, если сравнивать с аналогичным но более старым и проверенным. И в этом легко убедиться: поиск "linux ipv4" по CVE выдаёт 4 результата за 2023 год, а аналогичный для ipv6 выдаёт 11.
А почему только за 2023 год? Я вот сделал поиск по всей базе, и для "linux ipv4" нашлось 84 результата, а для "linux ipv6" -- 88 результатов. Огромная разница, ага. Причём подавляющее большинство их вообще никак не относилось к разнице между реализациями протокола IP этих версий.
Кстати, по "linux netware" за всё время нашлось аж 5 уязвимостей. По вашей логике, его код, получается, в 16 раз более защищён, чем IP.
Все эти "для безопасности/приватности" фичи реализованы, но по умолчанию все они выключены.
Вы в этом видите большую проблему? Добавить\поменять один небольшой скриптик в установщике дистра?
Как думаете, какой процент устройств в домашних локалках будет их использовать
А вы как думаете, какой процент устройств в домашних локалках будет линуксом? :)
Потому как я лично видел RFC 8981 на виндах включённый и работающий под SLAAC по умолчанию ёщё, емнип, на Windows 7.
и скажется ли это хоть как-то на общей ситуации с безопасностью? (Вопрос риторический.)
Никак. Проникновения, для которых требуется находить конкретную жертву по ёё IP, выловленному на скомпрометированном ресурсе, занимают доли процента на фоне всяких фишингов. С тех пор, как нетбиос перестал торчать в инет, я даже не припомню ни одной атаки такого класса.
В IPv6 просто гораздо меньше сценариев, которые требуют человеко-читать IP адрес.
которые к тому же будут привязаны к оператору (поменяли оператора - поменялись все адреса в локалке)
RFC 6275 вам в помощь.
, то с IPv6 так не получится.
Это почему вдруг? Прекрасно раздаётся статика хоть по slaac хоть по dhcp6.
Попробуйте представить, что нужно сделать SOHO админу, что бы перевести все на IPv6
Переводил всё на IPv6, вернее на дуалстэк в одной конторе. Ничего более сложного чем поднятие пары демонов на пограничном роутере и некоторых локальных заморочек с pac-скриптом.
Адрес - информация не секретная. Он виден на каждом ресурсе, к которому обратился
В IPv6 -- секретная.
Интерфейс, кроме основного адреса может нахватать сколько угодно дополнительных-временных, с которых и будет ходить на все нужные ресурсы и не принимать коннекты на них. А принимать только на основном, который не светится нигде, кроме явно указанных мест.
IPv4 так не сумеет, если только вы не купите по паре белых айпи каждой рабочей станции :)
Я нигде не утверждал, что Торвальдс поступил правильно.
Потребуются весьма нетривиальные доказательства, что в таком случае жертвой насилия является именно Гитлер. Причём, после того, как он это "заслужил", так сказать. И доказательства убедительные, а не просто сказки о распятых мальчиках.
Я не собираюсь тут заниматься словесным жонглированием. Мне достаточно и того, что поступки однозначно предосудительные, вне зависимости ни от чего — существуют.
Только с точки зрения трусов, которых обижает наличие своих принципов у других людей.
Опять же, те люди, в чьей этической системе трусость не является плохим качеством, не имеют права осуждать тех, у кого есть своя позиция и принципы.
Потому, что есть категория конфликтов, не оставляющая пространства для личной трусости.
Например, жертва-насильник. Тут не может быть серой морали, жертва не должна учитывать интересы насильника, тут нет места виктимблеймингу, поиску поводов и оправданий, кто кого куда спровоцировал и т.п.
Поэтому ответ на вопрос "осуждаете ли вы половое насилие" -- это да или нет. Оба они честны, хотя и полярны этически. А ответ "я просто хочу быть человеком" -- это личная трусость.
То, что изъятие из списка мэйнтейнеров является наказанием -- далеко не очевидно. Может это действительно мера безопасности, и приплетать тут зиппенхафт как-то не алё.
Я не знаю, что вы называете "хайдингом", но я имел в виду RFC 8981
Определяюсь -- датчик температуры в квартире не является критическим оборудованием, не участвует в производственных процессах и выход его из строя не несёт ущерба. Поэтому он может торчать голой жопой в интернет, а ваши свитчи и всё, что под ними -- не могут.
Где обсуждаем? С ipv6 файрволл на устройстве тоже не нужен, если он настроен на МЭ, где его настройка полностью аналогична v4.
Нет смысла угадывать. Вы могли там каждому датчику хоть по Старлинку или Иридиуму выдать, откуда я знаю? Спектр возможных вариантов тут очень широк -- от банальных EDGE модулей до какого-нибудь AFSK поверх ISM радио.
Какое всё это отношение имеет к простоте деплоя IPv6 в сетях?
Допустим, одну. Или две, смотря как считать. А что? Ad hominem чешется? :)
Есть такой протокол, UPnP называется :)
IPv6 всё-таки разрабатывался, чтобы решить проблему исчерпания адресного пространства.
То, что он потенциально может вернуть Инету его изначальную идеологию p2p это, конечно, хорошо, но мы, кажется, уже плотно в эпохе облаков живём, и p2p нужен только гикам.
Не надо.
А я говорю о том, что телодвижений там будет или меньше, чем с IPv4, или ровно столько же.
А можно посмотреть, как выглядит "на всё и сразу"?
В том-то и дело, что не становятся. И телепатия тут не нужна, вы просто игнорируете огромного слона в маленькой комнате -- вам почему-то кажется, что все устройства, получившие в вашей сети белый IPv6 тут же полезут наружу и будут кричать "ау, я здесь" всем подряд потенциальным злоумышленникам. Но это не так.
Вы в курсе о рекомендуемых практиках выделения IPv6 диапазонов?
Чтобы начать что-то досить, его сначала нужно найти.
Давайте. Но тогда ваш довод не работает, так как вы аргументируете отсутствием поддержки того, чего в целевых сценариях применения там быть не может.
Хорошо, вы меня убедили. Действительно, нишевому оборудованию, которое по принятым практикам сетевой безопасности вообще в интернет нельзя пускать (ну или как минимум через пограничный файрволл) IPv6 не нужен и его там справедливо нет.
В следующий раз буду явно уточнять, что я имею в виду маршрутизаторы.
Вы или выдумываете проблему на ровном месте, или ваша последняя винда была в районе ХР.
В этом конкретном случае файрволл, встроенный в винду, разберётся за вас. И да, он по умолчанию запрещает всё, что не разрешено явно, даже пинги. А запрос на явное разрешение вылазит как только какая-то прикладная прога запрашивает листенинг на публичном интерфейсе. Тут же создаётся разрешающее правило для неё и всё работает. Для продвинутого софта я не поленился и поднял UPnP на пограничном роутере -- и тогда ещё более всё работает. От прихода IPv6 ничего в этой схеме принципиально не меняется.
Я не просто так задал этот вопрос — он с подвохом. Подумайте ещё раз. Как вы представляете себе получение доступа к устройствам внутри сети клиента, начиная с их обнаружения.
nat64 для любителей костылей из засохшего навоза.
И то, и другое — свитчи для промавтоматики, в сетях которой доступа к Инету вообще быть не должно, хоть по v4, хоть по v6.
А вот маршрутизаторов, хоть магистральных, хоть SOHO сегмента, без поддержки v6 таки уже давно нигде нет.
Вы прокручиваете те же самые аргументы, которые тут уже прокручивали до вас десятки раз под комментами в десятках подобных статей.
Это каких, например? Если встроенный firewall на устройстве не имеет заранее заданного разумного дефолта, то настраивать его придётся для обоих версий, что займёт примерно одинаковое количество времени. Если же он имеет разумный дефолт для v4, то его скопировать для v6 -- тривиальная задача.
А с чего вы взяли, что без nat'а к устройствам iot на ipv6 будет доступ по умолчанию?
Во-первых,
В ESP32 IPv6 поддерживается вендором через вполне себе официальный ESP-IDF, который умеет в dual stack.
У ESP8266 незрелость поддержки v6 -- это исключительно и только вопрос желания вендора. Туда не добавляют какие-то фишки разве что потому, что он считается low-end устройством по сравнению с ESP32.
Во-вторых, модернизировать их, по большому счёту, нет необходимости. Есть же NAT64 и другие решения.
Почему это займёт времени больше, чем всё то же самое для IPv4 ? IPv6 существенно умнее в плане автоматической настройки.
Найдите, пожалуйста. Очень хочу посмотреть на эту аномалию.
Извините, но то что вы тут написали -- это чушь.
Излучение радиоволн, как активная операция -- требует от телефона намного большей мощности (порядка 500-2000 миливатт), чем пассивное прослушивание эфира в режиме приёмника (около 10-50 миливатт).
Приёмник и так включён постоянно, не зависимо от того, есть сигнал базовой станции или нет. Если бы приёмник не был включён постоянно, базовая станция не могла бы его вызвать в любую секунду.
Paging group это не про отключение приёмника, это про рассылку бродкаста группе находящихся рядом терминалов в данной и в соседних ячейках, так как терминалы имеют свойство перемещаться в пространстве, и так их легче найти.
Это противоречит вашим же словам о том, что батарея разряжается быстрее. Так как нагревается она от повышенного тока, и, следовательно, мощности.
Какая-то ерунда написана. телефоны излучают только когда "слышат" базовую станцию и им надо ей что-то сообщить -- инициировать вызов, отправить сообщение, зарегистрироваться и т.п. Если станцию не слышно, они молчат и просто сканируют диапазон частот в поисках чего-нибудь.
Поздравляю, вы открыли теорему Котельникова.
Теорию я знаю, но не могу избавиться от ощущения что вы как-то уж слишком буквально ставите телегу формальных метрик впереди кодовой лошади. Впрочем, дело вкуса.
Но и писать такой код никто не будет, потому что это дольше, дороже, и бизнесу непонятно зачем нужно.
Будет. Как только IPv6 реально пойдёт в массы и станет востребован среди целевой аудитории, дистро-строители озаботятся более-менее безопасными дефолтами.
Очень оптимистичная оценка. Современный линух не так-то просто впихнуть в рамки типичного же современного IoT устройства. Малинообразные устройства так и не стали индустриальным стандартом, как для IoT так и вообще, так что там либо какая-нибудь экзотика типа VxWorks, либо винегрет из embedded OS, у которых стек tcp/ip не из линуха.
не все роутеры (есть роутеры на том же VxWorks), а процент десктопов незаметный.
Это мой личный опыт, скажем так, шапки, которая в годы молодости не всегда была белой.
Целевые атаки (именно на пен, а не тупой ддос) чрезвычайно редки. Целевые атаки на пен на клиентскую сторону -- чрезвычайно редки в квадрате. Все последние легендарные успехи на этом поприще -- фишинг, трояны в почте и социалка. Вы поинтересуйтесь, как спецслужбы вкорячивали Stuxnet иранцам — через виндовый autorun, ага.
И домножьте это на долю юзеров, которые ходят в инет с белых адресов сейчас и вам тоже это станет очевидно.
А может и не измениться. Вы этого не знаете заранее, а я вижу, что разработчики IPv6 на эту тему думали и предлагали решения, тот же RFC 8981.
Это какая-то очень эзотерическая логика. Чем меньше кода, тем больше его защищённость, серьёзно? Ну ок, давайте повыкидываем обработку эксепшнов, канареек из стэка выбросим, санитайзеры всякие, zerofill-аллокации, сборщики мусора, вот это всё. Сразу защищённее станет, ага.
А почему только за 2023 год? Я вот сделал поиск по всей базе, и для "linux ipv4" нашлось 84 результата, а для "linux ipv6" -- 88 результатов. Огромная разница, ага. Причём подавляющее большинство их вообще никак не относилось к разнице между реализациями протокола IP этих версий.
Кстати, по "linux netware" за всё время нашлось аж 5 уязвимостей. По вашей логике, его код, получается, в 16 раз более защищён, чем IP.
Очень странную вы метрику выбрали.
Вы в этом видите большую проблему? Добавить\поменять один небольшой скриптик в установщике дистра?
А вы как думаете, какой процент устройств в домашних локалках будет линуксом? :)
Потому как я лично видел RFC 8981 на виндах включённый и работающий под SLAAC по умолчанию ёщё, емнип, на Windows 7.
Никак. Проникновения, для которых требуется находить конкретную жертву по ёё IP, выловленному на скомпрометированном ресурсе, занимают доли процента на фоне всяких фишингов. С тех пор, как нетбиос перестал торчать в инет, я даже не припомню ни одной атаки такого класса.
Это слишком громко сказано -- "военные изобрели".
Максимум -- профинансировали разработку технологии, на развитии которой он потом был построен (не ими).
В IPv6 просто гораздо меньше сценариев, которые требуют человеко-читать IP адрес.
RFC 6275 вам в помощь.
Это почему вдруг? Прекрасно раздаётся статика хоть по slaac хоть по dhcp6.
Переводил всё на IPv6, вернее на дуалстэк в одной конторе. Ничего более сложного чем поднятие пары демонов на пограничном роутере и некоторых локальных заморочек с pac-скриптом.
В IPv6 -- секретная.
Интерфейс, кроме основного адреса может нахватать сколько угодно дополнительных-временных, с которых и будет ходить на все нужные ресурсы и не принимать коннекты на них. А принимать только на основном, который не светится нигде, кроме явно указанных мест.
IPv4 так не сумеет, если только вы не купите по паре белых айпи каждой рабочей станции :)
С чего вы взяли, что код, реализующий IPv6 как то более уязвим, чем код, реализующий IPv4 ?