Здравствуйте, ·, Вы писали:

N>>Ну это вообще уже суперхуцпа — взять совершенно другую дискуссию, в которой ты ничего не смог доказать кроме собственной вкусовщины, и связать с текущей темой намёками в стиле "он меня рыбкой назвал, значит, сукой обозвал".
·>В том топике я описал рекомендуемый способ работы с распределённой СКВ, поддерживающей мержи. Собственно ради возможности реализации таких спосбов работы такие СКВ и стали придумывать.
·>Ты вкусным называл подходы, традиционно принятые в централизованных СКВ, не умеющих мержить, типа svn.

Связь между одним и другим — твои ничем не обоснованные домыслы. Рекомендованность мержинга в строго определённом направлении, из-за которого мы и зацепились, аналогично.

·>Так и в этом топике ты не понимаешь суть архитектурных решений в ipv6, позволяющих создавать stateless схемы и добиться децентрализации. Ради этого и придумывали ipv6.

Такой же домысел.

N>>Спасибо, мне всё ясно.
·>У тебя систематическая ошибка мышления.

У тебя ошибки и чтения (не понимаешь что я пишу), и мышления (не понимаешь, насколько это будет очевидно).

Здравствуйте, Pzz, Вы писали:

N>>Вариант самоподписи для данной ситуации достаточно неплохой. Потому что когда у тебя железка перестаёт работать, потому что промежуточный элемент цепочки сертификатов просрочился по not after constraint, а обновить прошивку фиг, как-то обидно. Это одна из существеннейших проблем PKI.

Pzz>Обычно у принтера в евонной веб-морде есть кнопка, затолкать в него сертификат. Но вот видишь, даже и ты про это не знаешь

Да, я с принтерами по IP работал очень мало и в подобную ситуацию не попадал.
Но использование такой кнопки предполагает определённые знания, которые выше уровня локального админа (или же его надо использовать в режиме обезьяны).

Спасибо, буду иметь в виду. И всё равно подход типа "один корень для вендор+год" выглядит неплохо.

Я же больше думал не про принтеры — у которых хоть какие-то средства тут есть — а про более автономные устройства, к которым такое не прицепишь.

Pzz>А разве у промежуточных сертификатов дата протухания проверяется на текущий момент, а не на момент использования этого сертификата для подписи более следующего в цепочке?

Хм, это я попробую почитать. Но чисто из общей логики допустимость протухания промежуточного сертификата считаю маловероятной.
Пока что я видел только варианты с валидной датой у всех в цепочке: например, корень со сроком в 20 лет, затем второй под ним в 5 лет, и под ним уже целевой.

Здравствуйте, ·, Вы писали:

·>Врёшь. Цитат уж точно не было, а твои фантазии интересны только тебе.

Спасибо. На этом я предлагаю тебе больше мне не отвечать, всё равно ничего полезного не скажешь.

Здравствуйте, Shmj, Вы писали:

S>...Изначально сделали половой член в 4 дюйма, что явно мало. Я предлагаю сделать 8 дюймов и утверждаю что больше не нужно. А по стандарту же сделали 16 дюймов, т.к. боялись что не хватит. Ты хочешь 16 дюймов?

You will receive much more pleasure in your sraka if I have 16'!

Здравствуйте, Pavlo Smaktunovskiy, Вы писали:

PS>You will receive much more pleasure in your sraka if I have 16'!

Интересный ты человек. Правильно ли я понял, что предки переехали в Австралию в поисках лучшей жизни, когда тебе было года 3. Язык ты почти забыл. Местные девушки не доступны, т.к. не достен материально — не женился. И теперь стал передастом, тянет на извращения с мужиками и уже не можешь это внутри себя удерживать — прямо хочешь об этом говорить, делать каминг-ауты?

Здравствуйте, Shmj, Вы писали:

S>...Местные девушки не доступны, т.к. не достен материально — не женился...

I am happily married.

S>...И теперь стал передастом, тянет на извращения с мужиками и уже не можешь это внутри себя удерживать — прямо хочешь об этом говорить, делать каминг-ауты?

My gay in sraka friend, you have a problem...

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Константин Б., Вы писали:

T>>>И еще потом каждому роутеру объясняй, как роутить пакеты для каждого адреса, что вот эти два адреса принадлежат одноу клиенту, им можно друг с другом общаться, а вот другим адресам нельзя. И как только выдаем новый адрес кому-то, то не забыть сходить переконфигурировать роутеры и фаерволы. Спасибо. Чтобы этой голимотьей не заниматься, и придумали IPv6, на нем можно построить гораздо более простую и надежную инфраструктуру. Без центральных реестров адресов, без натов, без переконфигурирования фаерволов и роутеров на каждый чих.
КБ>>Люди делится на два типа. Те кто восхищаются ipv6 и те кто на самом деле администрирует сети.
·>А как насчёт третьего типа, у кого ipv6 уже настроен и работает?

Это первый тип.

КБ>>Для доступа в интернет ipv6 работает конечно замечательно.
КБ>>А вот если надо выставить что-то в интернет.... без "not recomended (tm)" костылей не настроишь ни маршрутизацию, ни фаерволы, ни dns.
·>А конкретно? По сути всё то же самое, все те же проблемы что в 4, но упрощается вся система, т.к. протоколы становятся stateless. Вместо NAT, DHCP сервера+клиента, вся логика в конечном устройстве.

Повторю. Если все что нужно — доступ (неограниченный) в интернет — то да SLAAC замечательно работает, всё упрощается и т. д.
А чтобы принять соединение нужно доступ устройству как-то разрешить, а для этого надо как-то знать его адрес, а адрес — случайный, поэтому надо использовать DNS, а в DNS тоже прописать нельзя, потому что адрес — случайный...
И вот тут-то появляется ненужный DHCPv6 который раздает адреса и заодно их в DNS прописывает и другие костыли...

Здравствуйте, Константин Б., Вы писали:

КБ>·>А конкретно? По сути всё то же самое, все те же проблемы что в 4, но упрощается вся система, т.к. протоколы становятся stateless. Вместо NAT, DHCP сервера+клиента, вся логика в конечном устройстве.
КБ>Повторю. Если все что нужно — доступ (неограниченный) в интернет — то да SLAAC замечательно работает, всё упрощается и т. д.
КБ>А чтобы принять соединение нужно доступ устройству как-то разрешить,
Не очень понял. Зачем принимать соединения обычному смертному хосту? Для какого-нибудь условного P2P в случае VoIP или torrent? Так это соответсвующий сервер обеспечивает после того, как сконфигурился "доступ (неограниченный) в интернет".

Тут надо отделить мух от котлет. Типичный DHCP-сервер это связка нескольких сервисов. Выдача адресов, аннонс и регистрация в DNS и ещё наверное что-то. Так что надо рассматривать отдельные вещи отдельно.

КБ>а для этого надо как-то знать его адрес, а адрес — случайный, поэтому надо использовать DNS, а в DNS тоже прописать нельзя, потому что адрес — случайный...
Не понял, а в чём разница-то? С ipv4 DHCP адрес тоже случайный и в DNS тоже прописывать нечего.
Есть, кстати, ещё rfc6106, DNSSL и RDNSS. Так что DHCPv6 не необходимость, а дело привычки и традиции.

КБ>И вот тут-то появляется ненужный DHCPv6 который раздает адреса и заодно их в DNS прописывает и другие костыли...
Ну, например, можно и https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
В любом случае, даже DHCPv6 может работать проще и надёжнее. Ему достаточно анонсировать префикс, а адреса выбираются клиентами случайно.

Здравствуйте, Константин Б., Вы писали:

КБ>Повторю. Если все что нужно — доступ (неограниченный) в интернет — то да SLAAC замечательно работает, всё упрощается и т. д.
КБ>А чтобы принять соединение нужно доступ устройству как-то разрешить, а для этого надо как-то знать его адрес, а адрес — случайный, поэтому надо использовать DNS, а в DNS тоже прописать нельзя, потому что адрес — случайный...
КБ>И вот тут-то появляется ненужный DHCPv6 который раздает адреса и заодно их в DNS прописывает и другие костыли...

Ну в этом моменте какая-то логика есть. В, условно говоря, 99% случаев локалка — динамическое выделение адресов с получением префикса по router discovery и поиск друг друга (типа, где принтер) по мультикастам типа UPnP, в этом случае ничего особо не нужно. (Я не знаю, как, например, ищется в этом случае доменный контроллер AD. Кто знает, пусть подскажет.) А если что-то более продвинутое, нужное оставшимся 1% или местам с более умным персоналом типа collocation-хостингов — там уже можно и озаботиться.

На практике тут, однако, возникает проблема кросс-редиректа между этими технологиями — то RD должен ответить "а иди-ка ты к DHCP", то наоборот — реализация имеет проблемы, сталкивался.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Константин Б., Вы писали:

КБ>>Повторю. Если все что нужно — доступ (неограниченный) в интернет — то да SLAAC замечательно работает, всё упрощается и т. д.
КБ>>А чтобы принять соединение нужно доступ устройству как-то разрешить, а для этого надо как-то знать его адрес, а адрес — случайный, поэтому надо использовать DNS, а в DNS тоже прописать нельзя, потому что адрес — случайный...
КБ>>И вот тут-то появляется ненужный DHCPv6 который раздает адреса и заодно их в DNS прописывает и другие костыли...

N>Ну в этом моменте какая-то логика есть. В, условно говоря, 99% случаев локалка — динамическое выделение адресов с получением префикса по router discovery и поиск друг друга (типа, где принтер) по мультикастам типа UPnP, в этом случае ничего особо не нужно. (Я не знаю, как, например, ищется в этом случае доменный контроллер AD. Кто знает, пусть подскажет.) А если что-то более продвинутое, нужное оставшимся 1% или местам с более умным персоналом типа collocation-хостингов — там уже можно и озаботиться.

Ну так в этих 99% и NAT44 замечательно работает и польза от ipv6 то какая?. Реклама же нам говорит что с ipv6 всё станет проще. Ну вот, далеко не всё становится проще. Даже та самая глобальная связность и всеобщий p2p не получается потому что даже домашние роутеры входящий ipv6 по умолчанию режут.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Константин Б., Вы писали:

КБ>>·>А конкретно? По сути всё то же самое, все те же проблемы что в 4, но упрощается вся система, т.к. протоколы становятся stateless. Вместо NAT, DHCP сервера+клиента, вся логика в конечном устройстве.
КБ>>Повторю. Если все что нужно — доступ (неограниченный) в интернет — то да SLAAC замечательно работает, всё упрощается и т. д.
КБ>>А чтобы принять соединение нужно доступ устройству как-то разрешить,
·>Не очень понял. Зачем принимать соединения обычному смертному хосту? Для какого-нибудь условного P2P в случае VoIP или torrent? Так это соответсвующий сервер обеспечивает после того, как сконфигурился "доступ (неограниченный) в интернет".

Ну нет. Неограниченный он только в одну сторону. А обратно его еще разрешать надо. Домашние роутеры например по умолчанию входящий ipv6 режут.

·>Тут надо отделить мух от котлет. Типичный DHCP-сервер это связка нескольких сервисов. Выдача адресов, аннонс и регистрация в DNS и ещё наверное что-то. Так что надо рассматривать отдельные вещи отдельно.

Ну вот эта связка нужна чтобы решить ОДНУ задачу. И то что тут мухи с котлетами и костылями вместе, а о нормальных решениях никто не подумал — это и есть проблема.

·>Ну, например, можно и https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol

Ну я о чем и говорю. Есть те кто восхищаются ipv6 и те кто знают что такое Neighbor Discovery Protocol и почему он тут упомянут ну совершенно не к месту.

Здравствуйте, Константин Б., Вы писали:

КБ>Ну так в этих 99% и NAT44 замечательно работает и польза от ipv6 то какая?. Реклама же нам говорит что с ipv6 всё станет проще. Ну вот, далеко не всё становится проще.

Да, реклама врёт.

КБ> Даже та самая глобальная связность и всеобщий p2p не получается потому что даже домашние роутеры входящий ipv6 по умолчанию режут.

Именно. Мечтания благообразных старцев в воздушных замках образца 1994 года, когда ещё даже ping of death не был известен, спама почти не было и все почтовые сервера релеили всем, пароля в пять символов было достаточно, и прочая и прочая.

А нам, следующим поколениям, бороться с последствиями работы этих мечтателей с альцгеймером.

Здравствуйте, Shmj, Вы писали:

SK>>Слушай, а можешь сформулировать простыми словами, для не очень умного человека — какую проблему ты хочешь этим решить?

S>Экономия ресурсов. 8 байт требуют меньше вычислительных мощностей и меньше памяти, чем 16. При этом 8 байт хватит для триллиона людей + каждому по 16 млн. личных адресов, что более чем достаточно. Разумно распределить — дело протокола, главное что их точно с большим запасом хватит нашей планете.

Слушай, а ты наверное и GUIDы освобождаешь, да?

Здравствуйте, Shmj, Вы писали:

S>Это слишком примитивное мышление. Нужно рассмотреть не 1 случай а множество вариантов, в т.ч. создание списка и поиск по хеш-коду. Там нужно сотни разных тестов провести, прежде чем сделать вывод.

Поиск по хэшу вообще не зависит от размера данных

Здравствуйте, пффф, Вы писали:

П>Поиск по хэшу вообще не зависит от размера данных

Зато вычисшение хеша зависит.

Здравствуйте, Shmj, Вы писали:

П>>Поиск по хэшу вообще не зависит от размера данных

S>Зато вычисшение хеша зависит.

Доли промилле от общего времени

Здравствуйте, Константин Б., Вы писали:

КБ>>>·>А конкретно? По сути всё то же самое, все те же проблемы что в 4, но упрощается вся система, т.к. протоколы становятся stateless. Вместо NAT, DHCP сервера+клиента, вся логика в конечном устройстве.
КБ>>>Повторю. Если все что нужно — доступ (неограниченный) в интернет — то да SLAAC замечательно работает, всё упрощается и т. д.
КБ>>>А чтобы принять соединение нужно доступ устройству как-то разрешить,
КБ>·>Не очень понял. Зачем принимать соединения обычному смертному хосту? Для какого-нибудь условного P2P в случае VoIP или torrent? Так это соответсвующий сервер обеспечивает после того, как сконфигурился "доступ (неограниченный) в интернет".
КБ>Ну нет. Неограниченный он только в одну сторону. А обратно его еще разрешать надо. Домашние роутеры например по умолчанию входящий ipv6 режут.
Что "нет"? Ты внимательно читаешь что я написал? Конечно разрешать надо, firewall называется. Как-будто входящий ipv4 не режут. В чём возражение-то?

КБ>·>Тут надо отделить мух от котлет. Типичный DHCP-сервер это связка нескольких сервисов. Выдача адресов, аннонс и регистрация в DNS и ещё наверное что-то. Так что надо рассматривать отдельные вещи отдельно.
КБ>Ну вот эта связка нужна чтобы решить ОДНУ задачу.
Не _нужна_, ставь телегу и лошадь правильно. Есть другие подходы к решению той же задачи.

КБ>И то что тут мухи с котлетами и костылями вместе, а о нормальных решениях никто не подумал — это и есть проблема.
"никто"? Не говори за всех.

КБ>·>Ну, например, можно и https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
КБ>Ну я о чем и говорю. Есть те кто восхищаются ipv6 и те кто знают что такое Neighbor Discovery Protocol и почему он тут упомянут ну совершенно не к месту.
Ты смешал котлеты с мухами и невнятно излагаешь мысли. Каюсь, телепат из меня никудышный.