Date: Fri, 01 Oct 2010 18:09:21 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: dougb@FreeBSD.org Cc: freebsd-net@FreeBSD.org, rpaulo@FreeBSD.org Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(4) Message-ID: <20101001.180921.203815983.hrs@allbsd.org> In-Reply-To: <4CA51544.9080103@FreeBSD.org> References: <4CA4E221.4060107@FreeBSD.org> <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> <4CA51544.9080103@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Fri_Oct__1_18_09_21_2010_045)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton <dougb@freebsd.org> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101001.180921.203815983.hrs>