From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 09:10:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A54A2106566B; Fri, 1 Oct 2010 09:10:01 +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 EA93A8FC12; Fri, 1 Oct 2010 09:10:00 +0000 (UTC) Received: from alph.d.allbsd.org (p2176-ipbf406funabasi.chiba.ocn.ne.jp [124.86.72.176]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.3) with ESMTP id o9199bM4026791; Fri, 1 Oct 2010 18:09:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id o9199aVn038900; Fri, 1 Oct 2010 18:09:37 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 01 Oct 2010 18:09:21 +0900 (JST) Message-Id: <20101001.180921.203815983.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4CA51544.9080103@FreeBSD.org> References: <4CA4E221.4060107@FreeBSD.org> <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> <4CA51544.9080103@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(Fri_Oct__1_18_09_21_2010_045)--" 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]); Fri, 01 Oct 2010 18:09:51 +0900 (JST) X-Spam-Status: No, score=-99.1 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL, USER_IN_WHITELIST,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org, rpaulo@FreeBSD.org Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Oct 2010 09:10:01 -0000 ----Security_Multipart(Fri_Oct__1_18_09_21_2010_045)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4CA51544.9080103@FreeBSD.org>: do> In any case I didn't say that 6rd was not useful at all. What I tried do> to make the case for is that its utility is limited, both in the do> absolute sense and in the temporal sense; and that because of these do> limitations the benefits that adding the code bring are outweighed by do> the costs of maintaining it past what will likely be its useful do> lifetime. do> do> My point about FreeBSD 9 is that if we add the 6rd code today, then do> release 9.0 in about a year, then support the RELENG_9 branch for 4-6 do> years that we will still be maintaining code that no one has any use do> for. Sorry if I wasn't clear. In my understanding the transition period from IPv4 to IPv6 will take a very very long time, not a year or two even if it happens eventually. Migration techniques like 6rd which are applicable to subscriber access in large-scale ISPs are discussed and being adopted as their service just around these few years. Some may have some different ideas about the transition, but at least there is a fact that many ISPs think some kind of automatic IPv4-IPv6 tunneling is useful for their IPv6 deployment and investigating its implementability. I am not sure how much useful the 6rd will be in the near future in reality. However, I believe it is something worth implementing because I am sure that market of v4/v6 dual-stack CPE is rapidly growing, it is possible 6rd becomes one of its key techniques, and the market is where embedded FreeBSD systems can be visible. So, if we fail implementing ones that people want in a timely manner, we will lose our seat as a good networking OS vendor. I agree that introducing additional complexity is not a good thing, but most of the techniques including 6rd can be implemented by using the existing code with small changes because after all they are ones to solve operational/administrative issues by some specific combinations of the basic IPv6 functionality. This is my thought in general. If you have specific comments on the implementation which may lead to unacceptable maintenance cost or something bad, please let me know. do> In contrast, the bit of my post that you snipped suggested that a do> better course of action would be to focus on the areas of our v6 stack do> that will be used for the lifetime of the protocol, like the do> performance penalty that currently exists for the v6 loopback device. There is no trade-off between improving robustness/performance of the basic functionality and adding a new protocol in this case. The negative impact of adding 6rd is quite small if any, and we have nothing to lose even if 6rd will be useless some day. -- Hiroki ----Security_Multipart(Fri_Oct__1_18_09_21_2010_045)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkylpUEACgkQTyzT2CeTzy0oXQCg3byCzm1NIR0ceFUaBcWr+/QZ ZJoAn0NLEPta3+ipOoq+Awoa70BfYJqS =dxZE -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Oct__1_18_09_21_2010_045)----