From owner-freebsd-hackers Fri Jul 23 3: 1:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 2AB7414F88 for ; Fri, 23 Jul 1999 03:01:46 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id TAA09130; Fri, 23 Jul 1999 19:01:41 +0900 (JST) To: Jeroen Ruigrok/Asmodai Cc: hackers@FreeBSD.ORG In-reply-to: asmodai's message of Fri, 23 Jul 1999 10:39:42 +0200. <19990723103942.C9276@daemon.ninth-circle.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Will FreeBSD ever see native IPv6 ?? From: itojun@iijlab.net Date: Fri, 23 Jul 1999 19:01:41 +0900 Message-ID: <9128.932724101@coconut.itojun.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> We (KAME) are using 3.2-RELEASE and 2.2.8-RELEASE because we can't >> base our IPv6 development on top of moving target. >> FreeBSD 3.x-STABLE and 4.x are moving target (which moves very quickly) >> and are unusable as base version for us - if we need to chase two >> moving things (IPv6 and FreeBSD) we are doomed. >Problem being is that the 2.2.x branch has been declared obsolete and dead >by the Project. >If serious development work is being done CURRENT has always been the >targetted platform. But let's not nitpick about decissions make months >earlier. >However, 3.2-STABLE isn't that fast moving forward, and I doubt, based on >earlier discussions about touching the 3.x branch, that Jordan will allow >IPv6 to be entered into the 3.x branch (however TPTB may judge otherwise). >So 4.x seems like the only alternative left... I can't tell KAME users like: "Oh, if you would like to apply KAME diffs you'll need to fetch FreeBSD 4.x of June 1st". KAME needs to stick to x.y-RELEASE either, KAME have no choice anyways. >And I am still working on that =) Thanks for the effort! >> There has been NRL/INRIA/KAME integration work going on (basically >> to avoid "4 BSDs and 3 IPv6 = 12 choices" nightmare by making one >> IPv6 stack). There are, mainly, some (or too many) management >> issues there. We will be resolving management issues issue very soon, >> hopefully by next week. >That's good new ITOJUN-san, but I hope you can understand that after seeing >OpenBSD deploy IPv6 and NetBSD-CURRENT getting the IPv6 code merged by you, >that FreeBSD (read the userbase/developers) is anxious to also incorporate >this. I talked with core@freebsd.org several times about IPv6/IPsec integration, and the reaction was that: FreeBSD can wait till unified-ipv6 is made available, since: - IPv6 is not that urgent task and - it will be messy if FreeBSD integrates KAME first, then switch to unified-ipv6. (making a big change twice for IPv6 is questionable route) So we are in the current situation. (or maybe I was not pushing hard enough) NetBSD merged in KAME code last month, because NetBSD will have feature freeze for 1.5 soon and needed IPv6 code earlier than that. If I miss 1.5, it will not be able to be merged until 1.6 (planned to be sometime late 2000, I heard). NetBSD will be switching to unified codebase whenever it is made available (so NetBSD decided to make a big change twice). >> There's incomplete "unified" codebase there, which is not very >> ready for public consumption. Anyway please hold till the managment >> issue is resolved, I believe I can give you a good news. >Let me ask one question: if a few of us got the 3.x kit of kame up to 4.x >level and it got all commited would it make the `merged' stack easier to >integrate into CURRENT or does the stack-project prefer to use a clean >codebase? I myself think the first, which allows our driver writers time >to adjust to IPv6 changes, get a lot of still-present bugs out and basically >restabilize the system before the next IPv6 changes. Not to mention allow >people to test/work with IPv6 already. Here's my question: how much patch rejection you saw when you tried to apply KAME/FreeBSD32 patch onto 4.0? Were there many of these, or very few? If they are very few, and core@freebsd is okay, I think KAME can be merged into 4.0 tree first, then FreeBSD can switch from KAME to unified whenever it becomes ready (just like NetBSD does). Hopefully KAME and unified-ipv6 will not be that different, except for dual-stack tcp part (KAME code used separate tcp4/tcp6 for a long time, due to maintenance and stability reasons. The way unified code does dual-stack tcp is different from what KAME does). Userland part can be reused without trouble. There are, however, several drawbacks in doing that: - Now we have multiple KAME/FreeBSD[34] repository, one is in KAME site and one is in freefall.freebsd.org. Synchronizing those tree is a big problem. KAME already have problems synchronizing code between platforms we support, the merge will increase the problem. - Manpower issues. We need to continue providing KAME/FreeBSD32 anyways, for people who wants more stable IPv6/IPsec systems. We can't just tell everybody to switch to 4.0 and chase FreeBSD-current. - We need some more FreeBSD commit privs for other KAME guys. (this is a easy part) - again, two big changes for IPv6? Impacts on IPv4 stability? itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message