From owner-freebsd-net@freebsd.org Wed Jun 14 12:34:34 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E6D2D8D041 for ; Wed, 14 Jun 2017 12:34:34 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C70C1674 for ; Wed, 14 Jun 2017 12:34:34 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 3wnmKf2Jz9zRn; Wed, 14 Jun 2017 14:34:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1497443665; x=1500035666; bh=nSF opMqJjETNrA7hhoLxlZ7mnSplTV9CD/wrBQBvmKE=; b=ainqbTiOI6F/+CzfJmF SBTOEb9nDvCIVrhPmdmEQCS8NrkYY0zp6b3hkv7vOnaLxNSt18EYZwBdo0OJb60o pxmegSHfOZbwxZ7VXeKD7EpI3+WX/F6sEv857JxOzsCSifhVnJnmeiXe/8+fH/mc gMpY2Kl/XduZaOMQ390GBZq0= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id DIHZiPj3IaD3; Wed, 14 Jun 2017 14:34:25 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3wnmKY3HFjzRj; Wed, 14 Jun 2017 14:34:25 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3wnmKY31dLznC; Wed, 14 Jun 2017 14:34:25 +0200 (CEST) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by nabiralnik.ijs.si with HTTP (HTTP/1.1 POST); Wed, 14 Jun 2017 14:34:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 14 Jun 2017 14:34:25 +0200 From: Mark Martinec To: freebsd-net@freebsd.org Cc: Garrett Wollman , Rui Paulo Subject: Re: Enable IPv6 Privacy Extensions by default Organization: Jozef Stefan Institute In-Reply-To: <1497417261.2220.5.camel@me.com> References: <20170611215904.4612ee41@kalimero.tijl.coosemans.org> <20170612131912.42537b13@kalimero.tijl.coosemans.org> <1497408664.2220.3.camel@me.com> <201706140257.v5E2vRDE029173@hergotha.csail.mit.edu> <1497417261.2220.5.camel@me.com> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.2.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 12:34:34 -0000 The temporary (i.e. "privacy addresses", RFC4941) address use is a no-no for enterprise environments, which require address (user) accountability and stability. It is also inappropriate for servers. Add to this the nightmare of multicast caches overflowing in routers (as mentioned by others). The common advocacy for temporary addresses is hiding the MAC address and preventing location tracking for mobile computers. Both of these problems are addresses/solved by "Stable, Semantically Opaque IIDs": [RFC7217] "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", which retains the benefits of SLAAC, hides MAC addresses and ensures the IID changes when a computer moves to another network - without disadvantages of temporary ("privacy") addresses. Please do not enable classical RFC 4941 temporary addresses by default! I think it is a about time that FreeBSD makes it possible to configure "Stable, semantically opaque" address with a simple rc.conf setting, as some other™ operating systems have done by now! The RFC 7721 (IPv6 Address Generation Privacy) summarizes the "Stable, semantically opaque" address selection mechanism as follows: 4.5. Stable, Semantically Opaque IIDs [RFC7217] specifies an algorithm that generates, for each network interface, a unique random IID per IPv6 link. The aforementioned algorithm is employed not only for global unicast addresses, but also for unique local unicast addresses and link-local unicast addresses since these addresses may leak out via application protocols (e.g., IPv6 addresses embedded in email headers). A host that stays connected to the same IPv6 link could therefore be tracked at length, whereas a mobile host's activities could only be correlated for the duration of each network connection. Location tracking is not possible with these addresses. They also do not allow device-specific exploitation or address-scanning attacks. To repeat what I have recently written elsewhere: | I wish FreeBSD would adopt the dhcpcd daemon from the NetBSD project | (2-clause BSD license) as a standard DHCP client for IPv4 and IPv6, | as some other OSes have done by now. It is currently available in | FreeBSD ports as net/dhcpcd. | | Among other features it supports RFC 7217, i.e. stable privacy address, | which should be as easy to configure in FreeBSD as is now the | (mostly undesirable) ipv6_privacy="YES", but is currently much | too complicated for an average user. Mark 2017-06-14 07:14, Rui Paulo wrote: > On Tue, 2017-06-13 at 22:57 -0400, Garrett Wollman wrote: >> In article <1497408664.2220.3.camel@me.com>, rpaulo@me.com writes: >> >> > I don't see any reason why we shouldn't have privacy addresses >> > enabled >> > by default.  In fact, back in 2008 no one voiced their concerns. >> >> Back in 2008 most people hadn't had their networks fall over as a >> result of MLD listener report implosions when a thousand machines >> report (via multicast, natch) their eight[1] single-member >> solicited-node multicast groups in the space of a few seconds. >> >> -GAWollman >> >> [1] Assuming the vendor actually implemented the thing correctly. >> Some of us have seen what happens when one machine reports eight >> hundred single-member solicited-node multicast groups in the space of >> a few milliseconds. > > Pretty sure these problems have been addressed by now, given the amount > of computers, smart phones, tablets, etc. running with privacy > extensions enabled. > > If you still think this is a big problem, then FreeBSD could simply > implement CGA .