yup, makes sense. OK
On 2018 Mar 07 (Wed) at 18:29:07 +0100 (+0100), Florian Obser wrote:
:RFC 7136 clarifies that the "u" and "g" bits are only significant when
:IPv6 unicast interface identifiers are derived from IEEE link-layer
:addresses. In all other cases the interface identifier should be
:treated as an opaque value.
:
:Accordingly stop fiddling with the bits for privacy addresses.
:
:While here initialize the whole priv_in6 struct with random data,
:currently no functional change but reduces amount of magic numbers,
:pointed out by phessler as part of a larger diff.
:
:OK?
:
:diff --git slaacd/engine.c slaacd/engine.c
:index f2424c392f2..ab955c3b5e3 100644
:--- slaacd/engine.c
:+++ slaacd/engine.c
:@@ -1243,18 +1243,6 @@ gen_addr(struct slaacd_iface *iface, struct radv_prefix
*prefix, struct
: /* XXX from in6.h, guarded by #ifdef _KERNEL XXX nonstandard */
: #define s6_addr32 __u6_addr.__u6_addr32
:
:- /* XXX from in6_ifattach.c */
:-#define EUI64_GBIT0x01
:-#define EUI64_UBIT0x02
:-
:- if (privacy) {
:- arc4random_buf(_in6.s6_addr32[2], 8);
:- priv_in6.s6_addr[8] &= ~EUI64_GBIT; /* g bit to "individual" */
:- priv_in6.s6_addr[8] |= EUI64_UBIT; /* u bit to "local" */
:- /* convert EUI64 into IPv6 interface identifier */
:- priv_in6.s6_addr[8] ^= EUI64_UBIT;
:- }
:-
: in6_prefixlen2mask(_proposal->mask, addr_proposal->prefix_len);
:
: memset(_proposal->addr, 0, sizeof(addr_proposal->addr));
:@@ -1275,6 +1263,7 @@ gen_addr(struct slaacd_iface *iface, struct radv_prefix
*prefix, struct
: addr_proposal->mask.s6_addr32[3];
:
: if (privacy) {
:+ arc4random_buf(_in6.s6_addr, sizeof(priv_in6.s6_addr));
: addr_proposal->addr.sin6_addr.s6_addr32[0] |=
: (priv_in6.s6_addr32[0] & ~addr_proposal->mask.s6_addr32[0]);
: addr_proposal->addr.sin6_addr.s6_addr32[1] |=
:
:--
:I'm not entirely sure you are real.
:
--
Just go with the flow control, roll with the crunches, and, when you
get a prompt, type like hell.
