From owner-freebsd-current@FreeBSD.ORG Sun Apr 18 19:09:02 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01EEC106564A; Sun, 18 Apr 2010 19:09:02 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA358FC1E; Sun, 18 Apr 2010 19:09:01 +0000 (UTC) Received: from delta.allbsd.org (p4178-ipbf1907funabasi.chiba.ocn.ne.jp [114.146.127.178]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o3IJ8bpd075369; Mon, 19 Apr 2010 04:08:48 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o3IJ8ViC002212; Mon, 19 Apr 2010 04:08:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 19 Apr 2010 04:04:57 +0900 (JST) Message-Id: <20100419.040457.248129042.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4BCA2B55.9000609@FreeBSD.org> References: <4BC8EE88.6000700@FreeBSD.org> <20100417.233957.145060369.hrs@allbsd.org> <4BCA2B55.9000609@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Apr_19_04_04_57_2010_699)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 19 Apr 2010 04:08:54 +0900 (JST) X-Spam-Status: No, score=1.7 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, FORGED_RCVD_IP,RCVD_IN_PBL,SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, bz@FreeBSD.org Subject: Re: IPv6 configuration in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 19:09:02 -0000 ----Security_Multipart(Mon_Apr_19_04_04_57_2010_699)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4BCA2B55.9000609@FreeBSD.org>: do> > I strongly disagree with this because some IPv6 do> > applications depend on link-local address automatically added on do> > cloned interfaces do> do> Can you please give a configuration example that would create the do> scenario you are describing with the current code? And assuming that you We now have no control for whether a link-local address is automatically added or not when simply doing the following: # ifconfig gif0 create # ifconfig gif0 up IPv4 people hates that gif0 has an IPv6 link-local (and IPv6 communication itself), and IPv6 people hates that it needs an additional step to enable it (ifconfig inet6 -ifdisabled in this case). gif (and other cloned interfaces) can be created by a program (a ppp script, for example), so we cannot prepare $ifconfig line in rc.conf in advance. In short, if we have no knob to control this and put ifdisabled onto interfaces with no $ifconfig_IF_ipv6 line by default, people always needs "ifconfig inet6 -ifdisabled" for such dynamically created interfaces. This was the reason why $ipv6_prefer=YES did "ifconfig inet6 -ifdisabled" on interfaces with no $ifconfig_IF_ipv6 line and ipv6_prefer was NO by default. There are third party programs that use the above example to establish IPv6-over-IPv4 tunnel. The requirement of "-ifdisabled" will be very frustrating for IPv6 people. I admit "two meanings (src addr selection and -ifdisabled) in one $ipv6_prefer variable" is suboptimal, but at that time I thought factoring out them was rather troublesome. While my goal was to eliminate/factor such a opaque flag completely, this is the one unresolved. I still have no solution about this. do> And as I said above, this makes no sense. Clean, consistent UI design do> mandates that each knob have a specific, well defined function. As an do> example of why what you're suggesting is a bad idea, how would a user do> specify that they want link-local addresses on an interface, but they do do> NOT want the other effect of ipv6_prefer (the ip6addctrl settings)? I think that is a reasonable question. It was a loose end of the changes last year; I did not want to add additional knob to solve the problem explained above, so I decided to keep it coupled with the link-local thing until we get a solution. IMO, the src addr selection is supposed to be controlled by $ip6addrctl_* prefixed variables, and $ipv6_prefer should be removed in the long-term. do> > Also, source address selection has to be IPv4-preferred by default. do> > Why did you change this? I disagree with this. I want "IPv6 enabled do> > by default", but we are not ready for "IPv6 is preferred when the do> > both are available" for various reasons. do> do> Two reasons, in roughly equal importance. First, it has always been true do> that if IPv6 configuration is enabled IPv6 transport is preferred. do> Changing that now would be a POLA violation. Second, (as I stated do> previously) if the user takes the proactive step to configure IPv6 it is do> entirely reasonable to assume that they also want it to be tried first. In the default configuration (no rc.conf), there is no ifconfig_IF_ipv6 line. If we take this as no configuration for IPv6, should IPv6-preferred be disabled in this case? do> FWIW, I've been using IPv6 on FreeBSD for about 6 years now, and other do> than the very occasional glitch on the content-provider side it's been do> smooth sailing. Given that the default has been the equivalent of do> "ipv6_prefer=yes" all that time, I don't see any problem with leaving it do> that way, and as I said above I think defaulting it to off would be the do> wrong decision. It's probably also worth pointing out that in the case do> of ipv6_prefer=yes and no IPv6 configured on an external interface, the do> _prefer knob is moot. For IPv4 people, performance regression will be noticeable. IPv6-preferred src addr selection means ::1 is always used for localhost. On my box, IPv6 loopback is 25-30% slower than IPv4 counterpart. Whether this is critical or not depends on the application, but forcing IPv4-only people to use IPv6 loopback does not look a smart choice to me until we solve this problem though I love to see IPv6-preferred by default. do> > That behavior was intentional. do> do> I'm sorry to hear you say that, as I was hoping that it was simply an do> honest mistake on your part. To be clear, ipv6_prefer should control do> one, and only one thing, the behavior of rc.d/ip6addctrl. Overloading it do> in any way, and more importantly overloading it to require that it be on do> for any IPv6 configuration to occur at all is not acceptable. There do> _must_ be a way for users to configure IPv6 for their external do> interfaces and also have it not be preferred. do> do> Regardless of how you intended it at the time, adding an ipv6_prefer do> knob to control the behavior of rc.d/ip6addctrl is a good idea, and a do> valuable addition to FreeBSD. Overloading it to perform other functions do> is not acceptable. The reason I left two things in one variable is as explained earlier. I agree that they should be separated from each other, but please consider why I did so and solution to the problems *before* committing your change. I have continued to write lengthy emails because I am responsible to explain what I did that are mostly undocumented. I do not think my implementation is the best, so please do not take my opinion as a simple disagreement against your idea. I am interested in other people's view for the issues I showed and before further changes I want to discuss the direction we take even if it involves lengthy email exchanges. -- Hiroki ----Security_Multipart(Mon_Apr_19_04_04_57_2010_699)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkvLV9kACgkQTyzT2CeTzy2/egCcCvmypwaEr3f6Y8AhzreHlvj2 L3gAn2TEottqDQIwj4Mb5MlJ+Ixblk+U =8x5s -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Apr_19_04_04_57_2010_699)----