From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F3EAC169C4 for ; Sun, 3 Feb 2019 21:40:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6BB262177E for ; Sun, 3 Feb 2019 21:40:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727746AbfBCVkQ (ORCPT ); Sun, 3 Feb 2019 16:40:16 -0500 Received: from smtp3.strotmann.de ([46.38.233.133]:42688 "EHLO smtp3.strotmann.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727364AbfBCVkP (ORCPT ); Sun, 3 Feb 2019 16:40:15 -0500 X-Greylist: delayed 543 seconds by postgrey-1.27 at vger.kernel.org; Sun, 03 Feb 2019 16:40:14 EST Received: from smtp2.strotmann.de (unknown [IPv6:fd00::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id 1C4B17FE39; Sun, 3 Feb 2019 22:31:04 +0100 (CET) Received: from csmobile4.home.strotmann.de (unknown [IPv6:fd00::1000]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by smtp2.strotmann.de (Postfix) with ESMTPSA id 43t3tH73dlzgB2; Sun, 3 Feb 2019 22:31:03 +0100 (CET) To: davem@davemloft.net, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@vger.kernel.org, fgont@si6networks.com From: Carsten Strotmann Subject: Linux kernel and RFC 7217 support Message-ID: Date: Sun, 3 Feb 2019 22:31:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-0.10 / 15.00] ARC_NA(0.00)[] RCVD_VIA_SMTP_AUTH(0.00)[] FROM_HAS_DN(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] MIME_GOOD(-0.10)[text/plain] TO_DN_NONE(0.00)[] RCPT_COUNT_FIVE(0.00)[5] FROM_EQ_ENVFROM(0.00)[] MIME_TRACE(0.00)[0:+] RCVD_COUNT_TWO(0.00)[2] MID_RHS_MATCH_FROM(0.00)[] RCVD_TLS_ALL(0.00)[] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 0.80 X-Rspamd-Queue-ID: 1C4B17FE39 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, I'm testing IPv6 stable-secret identifiers SII under Linux RFC 7217. One important feature of RFC 7217 is to deliver stable IPv6 addresses for server addressing use that will not change in case of new network hardware (changed hardware address). Besides other benefits of SII, this is an important feature compared with EUI64 IPv6 addresses. However during my testing, the SII addresses were always changing when changing the network hardware address. After investigating into NetworkManager (Red Hat), wicked (SUSE) and disabling all these, working with the kernel alone and sysctl values, the issue was still showing. I'm not a C programmer, but I took a look into the source code and in linux-4.20.6/net/ipv6/addrconf.c I found: [...] sha_init(digest); memset(&data, 0, sizeof(data)); memset(workspace, 0, sizeof(workspace)); ---> memcpy(data.hwaddr, idev->dev->perm_addr, idev->dev->addr_len); data.prefix[0] = address->s6_addr32[0]; data.prefix[1] = address->s6_addr32[1]; data.secret = secret; data.dad_count = dad_count; sha_transform(digest, data.__data, workspace); temp = *address; temp.s6_addr32[2] = (__force __be32)digest[0]; temp.s6_addr32[3] = (__force __be32)digest[1]; [...] The marked line looks to me as if the interface hardware address is mixed into the SHA hash that will generate the SII address. Is this an correct observation? If yes, what is the rationale for this? If my suspected behavior of the Linux kernel is the true, it does really reduce the usefulness of IPv6 SII addresses in datacenter/enterprise environments. Best regards Carsten Strotmann