Ваша претензия была к времени fsck. На любой ФС без журнала (ну и не CoW) это будет долго, по очевидным причинам.
То, что вы написали про журнал, это похоже вы руками делали gjournal (10 лет назад возможно только такой вариант и был). Сейчас это автоматизированно можно сделать, просто одним аргументом к newfs. И производительность, похоже, тоже страдала из-за этого (хотя с журналированием она в любом случае просядет).
С SU вы всегда будете иметь консистентное (работающее) состояние ФС. Без него вы рискуете «терять» часть ФС, а то и всю. Без SU вы вынуждены всегда делать fsck при сбоях. С SU вы всегда можете подмонировать и работать с ФС. Единственное от чего SU не обезопашивает, так это от утечки места при сбоях (блоки диска могут быть помечены как занятые, хотя это не так): только для этого нужен fsck, время которого сокращается за счёт журнала.
SLAAC-ом (RA пакетом) выдаётся lifetime. Адрес штатно может меняться, как и префикс — всё так. Но постоянно работает NDP NUD чтобы понимать живность маршрутизатора. При смене префикса, для NDP есть особый «мобильный» режим работы, при котором мобильная нода очень часто опрашивает RA о его параметрах, чтобы минимизировать время простоя при смене адреса. Он быстро оповестит corresponding ноду о смене, снова произойдёт binding на новый адрес. Это штатно заложено всё в MIPv6. Повторюсь: в IPv6 работает NDP NUD (neighbour unreachability detection) как-раз чтобы быстро понимать отвалились ли мы и предпринять действия. При смене адреса мобильный агент сразу же оповестит домашнего.
vitus-wagner.dreamwidth.org/2144330.html хорошо описал опасности и проблемы и с DNS-over-HTTPS и, в добавок, выдачу миллиардов сертификатов Let's Encrypt-ом. Обе новости крайне плохи в вопросе безопасности и приватности.
Вы не правы касательно MIPv6. Точнее это зависит от реализации. В MIPv6 и при проксировании трафика через home agent и при прямой поссылки трафика с corresponding node на mobile agent, добавляется дополнительный IPv6 заголовок, говорящий что это как-бы адресовано home-of-address, а не care-of-address напрямую. При этом, скорее всего, будет использовать транспортный режим (host-to-host же). Корректная IPsec реализация должна учесть дополнительный IPv6 заголовок, превратив его в пакет как-будто с destination-ом равным HoA, а не CoA и поэтому для правил IPsec ничего не будет меняться при перемещении ноды. Так что тут никаких проблем не должно быть.
>Между ними лежит пропасть сильно большая, чем между IPv4 и IPv6.
Ваше субъективное мнение.
>То, что лично вам NAT чем-то мешает не делает его автоматически не нужным.
Штука которая делает неработоспособными любой протокол про который её явно не обучили? Какой бы костыль не был, но лучше без костылей.
>Что неожиданно легко решается NAT-ом.
Все ваши доводы по поводу NAT-а для меня выглядят абсолютно безумно нерациональностью. Вы представляете тяжеловесность NAT-а? Ну, в принципе что это за технология, как устроена? Очевидно что да. С таким же успехом, можно предлагать всё делать на прикладном уровне. Ну например HAProxy/nginx-ы разбирающие и балансирующие (или что там понадобится) HTTP запросы. Бывают места где без этого просто никак. А есть места где это сделать и просто, только крайне не эффективно с точки зрения ресурсов компьютеров. NAT относится к последнему. Просто все описанные вами usecase-ы, как их на лету подключать/отключать, меня конфигурацию и прочее — вовсю и по полной делается в ivi.ru, где я когда-то работал (не над сетями): о NAT-ах речи просто не может идти, когда трафик в сотни гигабит несколько лет назад был. Вопрос не в том что можно или нет решить эти задачи NAT-ом, а эффективно ли это или нет. Большинству людей просто поставить NAT на домашнем маршрутизаторе, чем писать правила firewall-а. Молоток предназначен для забивания гвоздей, а ещё им можно двери подпирать — это не значит что им стоит подпирать двери, если конечно он всё-равно при этом постоянно и для забивания гвоздей используется. В IPv6 мире, считайте, исчезла задача забивания гвоздей — молотку не место.
>Microsoft сделал. На Linux серверах такой проблемы вообще нет. Даже для Linux клиентов есть свои аналоги вроде zeroconf & etc.
Только из коробки эти zeroconf мало в каких дистрибутивах идут.
>Но я же и возмущаюсь, тем, что ICMPv6 здесь не привнес ничего нового, а повторил сделанное и в дальнейшем отвергнутое в IPv4/ICMP.
Ну, тут я и остановлюсь пожалуй, ибо в RFC NDP (одного только NDP!), раз в моей статье этого не видно, не одна страница сравнения с IPv4 и сколько он нового привнёс. Если не замечать и всего остального в таком же масштабе…
>Ближайший аналог — 2G/3G/4G. Инертность мышления не мешала переходу.
Они не так отличаются по сути работы своей.
>Вообще да, с отключенным кабелем действительно будет ещё безопаснее. Отсутствие полной симметричной связанности мешает лично вам, но для большинства потребителей интернета — эта плюс.
Не стоит их называть потребителями Интернета. Это потребители удалённых сервисов. Поднять IPsec между компьютерами они не смогут — какой же тут Интернет?
>NAT нужен
Единственное для чего он был нужен — как-то выжить в условиях нехватки IP адресов. На этом всём.
>Благодаря NAT, можно полностью переделать сегмент сети, с заменой сервисов в ней, протестировать всё это, в том числе на части живых пользователей и выкатить в прод незаметно для пользователей одной командой в консоли маршрутизатора. И в таких задачах у NAT замены нет.
Это решается маршрутизацией.
>Да. С этим хорошо в последних Linux. А вот варианты Windows-Linux-Cisco-Android и IPSec вызывают сильное неприятие всё этой радости. Изначальный IPSec имел не особо набор не особо стойких алгоритмов типа DES и кучу CVE в его разных реализациях.
Microsoft всегда в своём духе.
>Я писал, что ваша идея из статьи использовать вместо site-local глобальные префиксы, которые сменятся при смене провайдера — не очень практичная.
Ваша идея использовать site-local адреса, без очень веских на то причин (они могут быть, не спорю, просто не верю что часто), гарантированно вызовет геморрой при коллизии сетей объединённых VPN-ом.
>Он сложней 4-х трехзначных цифр. И сложность человеку работать с адресами — объективная проблема IPv6.
Это ваше субъективное мнение. Наверное мозг людей по разному устроен. Но мне абсолютно несвязанные 4 десятичных числа не просто запомнить, вот честно, правда.
>В IPv6 я вижу повтор этой истории.
Где-то есть опасения что адресов уже начало не хватать?
>Это живой пример, что link-local не завязаны на сетевой протокол. Можно было сделать отдельный, независящей от IPv4 и IPv6 протокол и внедрить в разных ОС.
Ну вот за столько десятков лет IPv4 так ничего подобного и не сделали чтобы везде было и работало. IPv6 сделал.
>Это результат эволюции и всевозможных атак из 90-х. Поэтому и странно видеть, как ICMPv6 пытается повторить похожий путь.
Мне то странно видеть что вы её кладёте на этот путь. По вашей логике вообще не нужно ничего нового изобретать и писать новый софт. Нет, я тоже в целом приверженец идеи «работает — не трожь» и противник «движения ради движения» (кто-то считает прогрессом ради прогресса), но всему есть разумные пределы применимости. Видеохостинг изначально можно поднять на одном сервере с хранением видео файлов на ФС как есть. Но с ростом популярности такого сервера, придётся делать системы как в ivi.ru, где работают сотни программистов и сетевых инженеров. IPv4 уже не удовлетворяет потребностям.
>Для обывателя SLAAC не привносит ничего нового — он не заметить разницы.
Обывателю достаточно оставить с дюжину сайтов типа YouTube, VK, FB, и т.д., а всё остальное отрубить — я уверен что 99% не заметят разницы тоже. Обыватели меня не интересуют.
>Решения о маршрутизации принимаются на основе фиксированного заголовка
>Сейчас, в IPv4 это работает так же.
Только заголовок обрабатывается сложнее (разная длина, плюс пересчёт checksum на каждом hop). А так да: в IPv6 аналогично, просто проще.
>Уже нет. Это сломает маршрутизацию. Железо из Tier 1 ради оптимизаций все, что ниже /64 маршрутизировать не будет ибо не реализовано. SOHO сегмент не может из-за совместимости с RA/DHCPv6 и текущими реализациями стеков. Адреса, как бы теоретически, 128-битные, но только маршрутизировать из них больше 64 уже не выйдет.
Вы придумываете. Когда у меня был /64, то я дробил на маленькие сети, между разными устройствами (FreeBSD машины). Про Tier1 ничего не скажу, но ok, там поверю что ради оптимизации они не смотрят на 64-бит. Там это крайний случай.
>Я может запамятовал, но на вскидку из 48 бит MAC генерировалось 64 нижней части. Ну или уже не так помню и тяжко лезть в RFC искать.
48 бит становятся 64 битами, да. Просто энтропии в этом адресе всё-равно 48 бит. Плюс два байта константы вставляются.
>Штуки вроде NDP говорят об обратном. Выдавать по local-link IPv6 каждому порту коммутатора в ЦОДах тоже никто вроде не предлагает. А Ethernet/WiFi преобладают безальтернативно и рассчитывать IPv6 под другой канальный уровень странно. Поэтому идеи о ptp как оправдание такой схемы адресации выглядят странно.
NDP как-раз говорит о том, что он адреса канального уровня явно может и не быть — поэтому поля переносящие *внутри* ICMPv6 link-layer адрес: опциональны. На самом деле отличная apenwarr.ca/log/20170810 статья как-раз и предлагает делать на каждом порте коммутатора IPv6 сеть сразу же. По сути же оно так уже и есть: у нас точка-точка соединения чисто физически.
>Это то, во что IPv6 эволюционировал.
IPv6 это RFC описывающие IPv6. Плюс NDP. Плюс ещё несколько. Не нужно приплетать странные (дурные) RFC ко всей кучи и считать что их или кто-то обязан реализовывать или хотя бы даже прислушиваться. Эти дурные вещи никто никуда не тащит, в здравом уме.
>Я не понимаю, почему вы думаете, что пришли какие-то левые люди и начали штамповать похабные RFC ломающие замысел первоначальных авторов.
Ну… потому что вот прям буквально так и думаю, действительно. Я программист и прекрасно знаю что можно делать костыли побыстрее, решая сиюминутные задачи. А можно хорошо что-то продумывать, просто сложнее и дольше внедрять потом придётся. Сколько коммитетов/разработчиков — столько и подходов может быть. Все они профессионалы, бесспорно, но я сам, будучи разработчиком, не со всеми разработчиками согласен в решениях. Текущая статья: полная солидарность с разработчиками IPv6/NDP/MIPv6/и т.д…
>Цена должна быть оправдана. ~24 года с создания IPv6, ~40 с создания IPv4. И протокол никак не рассчитанный под современную сеть менять не хотят. У нас в компании думали внедрять IPv6 ещё лет 7 назад, с регистрацией своих префиксов и т.д., но из-за отсутствия совместимости Dual Stack в те времена отставили IPv4. И всё, внедрение не состоялось.
Ну а в США больше половины трафика это IPv6 *уже*. Можно и дальше бесконечно вспоминать старые времена как оно не получилось. 7 лет назад SLAAC-RDNSS мало кто поддерживал, сводя на нет его как возможную замену DHCP. Я IPv6 пользуюсь уже 10+ лет, но только сейчас вот написал про него статью, только сейчас считаю что пора.
Ну многие плюсы IPv6 описаны тут: habr.com/ru/post/490378. Если IPv4 хочется иметь только для хождения по сайтикам из корпоративной сети, то можно использовать (я делал — работает) NAT64+DNS64. IPv4 dual stack хотя бы будет только на маршрутизаторе.
Лично у меня полно личных ресурсов/серверов где только по IPv6 можно попасть. Да и блоги людей я знаю которые доступны только по IPv6. Сейчас сложнее найти ресурсы которые бы *не* были доступны по IPv6 (к сожалению, удивительно, но до сих пор остаются ещё такие, тот же Хабр :-)).
То, что вы написали про журнал, это похоже вы руками делали gjournal (10 лет назад возможно только такой вариант и был). Сейчас это автоматизированно можно сделать, просто одним аргументом к newfs. И производительность, похоже, тоже страдала из-за этого (хотя с журналированием она в любом случае просядет).
С SU вы всегда будете иметь консистентное (работающее) состояние ФС. Без него вы рискуете «терять» часть ФС, а то и всю. Без SU вы вынуждены всегда делать fsck при сбоях. С SU вы всегда можете подмонировать и работать с ФС. Единственное от чего SU не обезопашивает, так это от утечки места при сбоях (блоки диска могут быть помечены как занятые, хотя это не так): только для этого нужен fsck, время которого сокращается за счёт журнала.
Ваше субъективное мнение.
>То, что лично вам NAT чем-то мешает не делает его автоматически не нужным.
Штука которая делает неработоспособными любой протокол про который её явно не обучили? Какой бы костыль не был, но лучше без костылей.
>Что неожиданно легко решается NAT-ом.
Все ваши доводы по поводу NAT-а для меня выглядят абсолютно безумно нерациональностью. Вы представляете тяжеловесность NAT-а? Ну, в принципе что это за технология, как устроена? Очевидно что да. С таким же успехом, можно предлагать всё делать на прикладном уровне. Ну например HAProxy/nginx-ы разбирающие и балансирующие (или что там понадобится) HTTP запросы. Бывают места где без этого просто никак. А есть места где это сделать и просто, только крайне не эффективно с точки зрения ресурсов компьютеров. NAT относится к последнему. Просто все описанные вами usecase-ы, как их на лету подключать/отключать, меня конфигурацию и прочее — вовсю и по полной делается в ivi.ru, где я когда-то работал (не над сетями): о NAT-ах речи просто не может идти, когда трафик в сотни гигабит несколько лет назад был. Вопрос не в том что можно или нет решить эти задачи NAT-ом, а эффективно ли это или нет. Большинству людей просто поставить NAT на домашнем маршрутизаторе, чем писать правила firewall-а. Молоток предназначен для забивания гвоздей, а ещё им можно двери подпирать — это не значит что им стоит подпирать двери, если конечно он всё-равно при этом постоянно и для забивания гвоздей используется. В IPv6 мире, считайте, исчезла задача забивания гвоздей — молотку не место.
>Microsoft сделал. На Linux серверах такой проблемы вообще нет. Даже для Linux клиентов есть свои аналоги вроде zeroconf & etc.
Только из коробки эти zeroconf мало в каких дистрибутивах идут.
>Но я же и возмущаюсь, тем, что ICMPv6 здесь не привнес ничего нового, а повторил сделанное и в дальнейшем отвергнутое в IPv4/ICMP.
Ну, тут я и остановлюсь пожалуй, ибо в RFC NDP (одного только NDP!), раз в моей статье этого не видно, не одна страница сравнения с IPv4 и сколько он нового привнёс. Если не замечать и всего остального в таком же масштабе…
Они не так отличаются по сути работы своей.
>Вообще да, с отключенным кабелем действительно будет ещё безопаснее. Отсутствие полной симметричной связанности мешает лично вам, но для большинства потребителей интернета — эта плюс.
Не стоит их называть потребителями Интернета. Это потребители удалённых сервисов. Поднять IPsec между компьютерами они не смогут — какой же тут Интернет?
>NAT нужен
Единственное для чего он был нужен — как-то выжить в условиях нехватки IP адресов. На этом всём.
>Благодаря NAT, можно полностью переделать сегмент сети, с заменой сервисов в ней, протестировать всё это, в том числе на части живых пользователей и выкатить в прод незаметно для пользователей одной командой в консоли маршрутизатора. И в таких задачах у NAT замены нет.
Это решается маршрутизацией.
>Да. С этим хорошо в последних Linux. А вот варианты Windows-Linux-Cisco-Android и IPSec вызывают сильное неприятие всё этой радости. Изначальный IPSec имел не особо набор не особо стойких алгоритмов типа DES и кучу CVE в его разных реализациях.
Microsoft всегда в своём духе.
>Я писал, что ваша идея из статьи использовать вместо site-local глобальные префиксы, которые сменятся при смене провайдера — не очень практичная.
Ваша идея использовать site-local адреса, без очень веских на то причин (они могут быть, не спорю, просто не верю что часто), гарантированно вызовет геморрой при коллизии сетей объединённых VPN-ом.
>Он сложней 4-х трехзначных цифр. И сложность человеку работать с адресами — объективная проблема IPv6.
Это ваше субъективное мнение. Наверное мозг людей по разному устроен. Но мне абсолютно несвязанные 4 десятичных числа не просто запомнить, вот честно, правда.
>В IPv6 я вижу повтор этой истории.
Где-то есть опасения что адресов уже начало не хватать?
>Это живой пример, что link-local не завязаны на сетевой протокол. Можно было сделать отдельный, независящей от IPv4 и IPv6 протокол и внедрить в разных ОС.
Ну вот за столько десятков лет IPv4 так ничего подобного и не сделали чтобы везде было и работало. IPv6 сделал.
>Это результат эволюции и всевозможных атак из 90-х. Поэтому и странно видеть, как ICMPv6 пытается повторить похожий путь.
Мне то странно видеть что вы её кладёте на этот путь. По вашей логике вообще не нужно ничего нового изобретать и писать новый софт. Нет, я тоже в целом приверженец идеи «работает — не трожь» и противник «движения ради движения» (кто-то считает прогрессом ради прогресса), но всему есть разумные пределы применимости. Видеохостинг изначально можно поднять на одном сервере с хранением видео файлов на ФС как есть. Но с ростом популярности такого сервера, придётся делать системы как в ivi.ru, где работают сотни программистов и сетевых инженеров. IPv4 уже не удовлетворяет потребностям.
>Для обывателя SLAAC не привносит ничего нового — он не заметить разницы.
Обывателю достаточно оставить с дюжину сайтов типа YouTube, VK, FB, и т.д., а всё остальное отрубить — я уверен что 99% не заметят разницы тоже. Обыватели меня не интересуют.
>Решения о маршрутизации принимаются на основе фиксированного заголовка
>Сейчас, в IPv4 это работает так же.
Только заголовок обрабатывается сложнее (разная длина, плюс пересчёт checksum на каждом hop). А так да: в IPv6 аналогично, просто проще.
>Уже нет. Это сломает маршрутизацию. Железо из Tier 1 ради оптимизаций все, что ниже /64 маршрутизировать не будет ибо не реализовано. SOHO сегмент не может из-за совместимости с RA/DHCPv6 и текущими реализациями стеков. Адреса, как бы теоретически, 128-битные, но только маршрутизировать из них больше 64 уже не выйдет.
Вы придумываете. Когда у меня был /64, то я дробил на маленькие сети, между разными устройствами (FreeBSD машины). Про Tier1 ничего не скажу, но ok, там поверю что ради оптимизации они не смотрят на 64-бит. Там это крайний случай.
>Я может запамятовал, но на вскидку из 48 бит MAC генерировалось 64 нижней части. Ну или уже не так помню и тяжко лезть в RFC искать.
48 бит становятся 64 битами, да. Просто энтропии в этом адресе всё-равно 48 бит. Плюс два байта константы вставляются.
>Штуки вроде NDP говорят об обратном. Выдавать по local-link IPv6 каждому порту коммутатора в ЦОДах тоже никто вроде не предлагает. А Ethernet/WiFi преобладают безальтернативно и рассчитывать IPv6 под другой канальный уровень странно. Поэтому идеи о ptp как оправдание такой схемы адресации выглядят странно.
NDP как-раз говорит о том, что он адреса канального уровня явно может и не быть — поэтому поля переносящие *внутри* ICMPv6 link-layer адрес: опциональны. На самом деле отличная apenwarr.ca/log/20170810 статья как-раз и предлагает делать на каждом порте коммутатора IPv6 сеть сразу же. По сути же оно так уже и есть: у нас точка-точка соединения чисто физически.
>Это то, во что IPv6 эволюционировал.
IPv6 это RFC описывающие IPv6. Плюс NDP. Плюс ещё несколько. Не нужно приплетать странные (дурные) RFC ко всей кучи и считать что их или кто-то обязан реализовывать или хотя бы даже прислушиваться. Эти дурные вещи никто никуда не тащит, в здравом уме.
>Я не понимаю, почему вы думаете, что пришли какие-то левые люди и начали штамповать похабные RFC ломающие замысел первоначальных авторов.
Ну… потому что вот прям буквально так и думаю, действительно. Я программист и прекрасно знаю что можно делать костыли побыстрее, решая сиюминутные задачи. А можно хорошо что-то продумывать, просто сложнее и дольше внедрять потом придётся. Сколько коммитетов/разработчиков — столько и подходов может быть. Все они профессионалы, бесспорно, но я сам, будучи разработчиком, не со всеми разработчиками согласен в решениях. Текущая статья: полная солидарность с разработчиками IPv6/NDP/MIPv6/и т.д…
>Цена должна быть оправдана. ~24 года с создания IPv6, ~40 с создания IPv4. И протокол никак не рассчитанный под современную сеть менять не хотят. У нас в компании думали внедрять IPv6 ещё лет 7 назад, с регистрацией своих префиксов и т.д., но из-за отсутствия совместимости Dual Stack в те времена отставили IPv4. И всё, внедрение не состоялось.
Ну а в США больше половины трафика это IPv6 *уже*. Можно и дальше бесконечно вспоминать старые времена как оно не получилось. 7 лет назад SLAAC-RDNSS мало кто поддерживал, сводя на нет его как возможную замену DHCP. Я IPv6 пользуюсь уже 10+ лет, но только сейчас вот написал про него статью, только сейчас считаю что пора.