netdev - enable/disable temporary IPv6 per prefix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 11 Sep 2016 09:29:16 +0200
From:   Oliver Mangold <o.mangold@...il.com>
To:     netdev@...r.kernel.org
Subject: enable/disable temporary IPv6 per prefix

Hi,

I have a question as a relatively new user to IPv6. I am wondering if it 
is currently possible to enable/disable the usage of temporary addresses 
on a per-prefix basis. My current understanding is that the feature is 
enabled by the the 'use_tempaddr' sysctl attribute, which is 
per-interface. What I would like to do is disable temp addresses for ULA 
prefixes. Did I miss something and this can already be done, or is it a 
feature planned for the future, maybe? RFC4941 seems to agree that this 
is a valid use case:

Additionally, sites might wish to selectively enable or disable the use 
of temporary addresses for some prefixes.  For example, a site might 
wish to disable temporary address generation for "Unique local" [ULA] 
prefixes while still generating temporary addresses for all other global 
prefixes.  Another site might wish to enable temporary address 
generation only for the prefixes 2001::/16 and 2002::/16, while 
disabling it for all other prefixes. To support this behavior, 
implementations SHOULD provide a way to enable and disable generation of 
temporary addresses for specific prefix subranges.  This per-prefix 
setting SHOULD override the global settings on the node with respect to 
the specified prefix subranges.  Note that the pre-prefix setting can be 
applied at any granularity, and not necessarily on a per-subnet basis.

Best regards,

Oliver