[devel-distro] per-distro use_tempaddr policy

[devel-distro] per-distro use_tempaddr policy

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 4149 bytes --]

Hi!

В последние годы границы применимости альта расширились, и приобрела
актуальность вот такая тема.

В IPv6 у хоста, проходящего процедуру SLAAC, есть несколько стандартных
способов себе сгенерировать правую, младшую часть адреса (старшую, левую
часть назначает оператор сети).
С одной стороны: на сервере удобно назначить широко известную младшую
часть. Один из способов (называется EUI64) опирается на IEEE-MAC48 адрес
и биективно генерит из него 64-битное значение.
С другой стороны: чтобы мобильный узел не светил своим EUI64
последовательно из разных сетей и изменения его IP-адреса во времени
не образовывали точную карту перемещений, введены:
* т. н. Privacy Extensions[8981], правые части со сроком жизни
  несколько часов;
* стабилизированные криптоотбеленные правые части[7217].

В результате получаем (не огр. общ.) два механизма, один из которых
совершенно неудобен для обеспечения ходьбы по ssh, а другой неприемлем
для персональных и особенно портативных устройств. Придумать дефолтное
изкоробочное значение, которое подойдёт почти всем и особенно
для неадминистрируемых машин (на которых некому его переназначить),
нельзя. Значит, поставлять удобный дефолт нужно в образах; потому и
написано текущее письмо.

В сизифе никакое решение на эту тему не принято, и это нормально.
дефолтное поведение берётся из пакетов (с ядром, NetworkManager, etc.),
повсюду оно "не включать privacy extensions".

Для каждого образа предлагаю авторам образов выбрать и включить
в его состав вариант:
  * не генерировать адресов с конечным сроком жизни
    (в ядре use_tempaddr = 0)
  * генерировать такие адреса, сделать их приоритетными
    для source address selection
    (в ядре use_tempaddr = 2)

В те образы, в комплекте которых идёт NetworkManager, во втором случае
можно ещё положить вот такое:

    # cat >/etc/NetworkManager/conf.d/51-use-tempaddr.conf <<-EOConf
    [connection]
    ipv6.addr-gen-mode=stable-privacy
    ipv6.ip6-privacy=2
    EOConf

В меру моего скромного разумения включить privacy extensions из коробки
совершенно точно нужно в мобильных образах и workstation-* и совершенно
точно не нужно на сервере. Всё остальное требует внимания автора образа.
Если устройство введено в домен, то к нему должна применяться доменная
политика (как правило, админы домена прибьют dyndns по ключу/билету
или персистентные адреса)

____
[8981] https://datatracker.ietf.org/doc/html/rfc4941
       https://datatracker.ietf.org/doc/html/rfc8981
[7217] https://datatracker.ietf.org/doc/html/rfc7217

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Re: [devel-distro] per-distro addr_gen_mode (aka stable-privacy) policy

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

On Mon Nov 9, 2026 at 6:17 PM MSK, Arseny Maslennikov wrote:
> чтобы мобильный узел не светил своим EUI64
> последовательно из разных сетей и изменения его IP-адреса во времени
> не образовывали точную карту перемещений, введены:
> * стабилизированные криптоотбеленные правые части[7217].
> ____
> [7217] https://datatracker.ietf.org/doc/html/rfc7217

Судя по практике нескольких лет, эти "стабильные криптопорождённые
адреса" оказываются не очень-то и стабильными:
https://t.me/s/version6/85693
но перемешиваются их биты хорошо.

Тем не менее, это второй вопрос к авторам образов, _независимый_ от
предыдущего: имеет ли вместо EUI64 смысл задействовать stable-privacy,
и, если да, то какую реализацию.

В облачной rootfs и в jeos точно нет (т. е. ничего можно не менять).
А в остальных случаях могут быть соображения.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Re: [devel-distro] Fwd: per-distro use_tempaddr policy

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]

On Mon Nov 9, 2026 at 6:55 PM MSK, Евгений Синельников wrote:
> 9 нояб. 2026 г. 19:18:08 UTC+4 Arseny Maslennikov <arseny@altlinux.org>:
> > Для каждого образа предлагаю авторам образов выбрать и включить
> > в его состав вариант:
> >   * не генерировать адресов с конечным сроком жизни
> >     (в ядре use_tempaddr = 0)
> >   * генерировать такие адреса, сделать их приоритетными
> >     для source address selection
> >     (в ядре use_tempaddr = 2)
> >
> > В те образы, в комплекте которых идёт NetworkManager, во втором случае
> > можно ещё положить вот такое:
> >
> >     # cat >/etc/NetworkManager/conf.d/51-use-tempaddr.conf <<-EOConf
> >     [connection]
> >     ipv6.addr-gen-mode=stable-privacy
> >     ipv6.ip6-privacy=2
> >     EOConf
> >
> > В меру моего скромного разумения включить privacy extensions из коробки
> > совершенно точно нужно в мобильных образах и workstation-* и совершенно
> > точно не нужно на сервере. Всё остальное требует внимания автора образа.
> > Если устройство введено в домен, то к нему должна применяться доменная
> > политика (как правило, админы домена прибьют dyndns по ключу/билету
> > или персистентные адреса)
>
> Привет.
>
> Чтобы получить такое поведение, что "если устройство введено в домен,
> то к нему должна применяться доменная политика", необходимо не только
> включение такого усиления безопасности предусмотреть, но и способы
> перенастройки.
>
> Наиболее простой и успешный метод сейчас - это создание control'ов.

Обернуть в control можно, да. Это мудрая идея.

Тут вступает в игру более общий недостаток control(8):
ему не хватает возможности применить все facilities в
инит-последовательности. Подобно тому, как применяются
tmpfiles.d и sysusers.d уже сейчас.
Это особенно уместно, например, в "атомарках" т. н.,
но полезно везде.

Но его исправлять нужно независимо от сабжа. :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]