From owner-freebsd-net@freebsd.org Fri Nov 24 19:55:37 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 6C8D0DF005F for ; Fri, 24 Nov 2017 19:55:37 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 048FD3202 for ; Fri, 24 Nov 2017 19:55:36 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id vAOJtWco024894 for ; Fri, 24 Nov 2017 20:55:32 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 5F408F17; Fri, 24 Nov 2017 20:55:32 +0100 (CET) Message-ID: <5A187930.1070406@omnilan.de> Date: Fri, 24 Nov 2017 20:55:28 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Net Subject: =?UTF-8?B?UTogW3J0YWR2ZF0gcHJlZml4IGluZm8gZmxhZyAnUicgLSBNb2JpbGU=?= =?UTF-8?B?IElQdjYgZXh0ZW5zaW9uIOKAkyBvciBob3cgdG8gZGlzYWJsZSBsaW5rLWxvY2E=?= =?UTF-8?B?bCBnYXRld2F5?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 24 Nov 2017 20:55:32 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 19:55:37 -0000 Hello, it was unavoidable, so I took some time reading rtadvd.conf(5), rfc4861 (Neighbour Discovery for IP version 6, which also describes the Router Advertisement Message Format with it's Prefix Information, flags L and A) and rfc6275 (Mobility Support in IPv6, which extends the Prefix Information Flags). As far as I can tell, our rtadvd(8) doesn't support the extended 'R' flag. My aim: Stateful _only_ (dhcp6) configuration in the LAN for widest client deversity possible, without the need to change anything on any client. dhcp6 setup was no probelm with isc's dhcpd. Finding the "managed adress" flag for RA messages, which tells most popular clients to _also_ request DHCPv6 leases was also no big effort. Finding the unwanted L flag for the prefix information in the RA message was a bit trickier. Finding out that rtadvd(8) seems to only respect the corresponding "pinfoflags='l'" capability field if you explicitly set a addr for prefix info (not leaving the auto-determination) was hard. So for the records, if somebody else want's to restrict SLAAC in her DHCPv6 environment, /etc/rtadvd.conf needs the following lines to convince the most popular clients to use the stateful (dhcp6) address for internet communication: yourdefaults:\ :noifprefix:nolladdr:raflags='m': yourif:\ :tc=yourdefaults:addr="2001:db8:abcd:1::":prefixlen#64:pinfoflags='l': (If you only set the 'm' flag, most popular clients use the SLAAC address, despite they got a dhcp lease.) In any case, they use the link-local address of the gateway. I'd prefer that clients use the global unicast address of the router, instead of the link-local address. What I found so far is the already mentioned "R" flag, but that's not implemented so far (in rtadvd(8)). What do your setups look like? Do you use radvd(8) instead? Any other trick? Not caring about source addresses at all? Thanks, -harry