Re: KAME IPv6 and freebsd
Itojun, does KAME IPv6 and IPSec define additional facilities for syslog? I have been working with IPSec devices from a company called Network-Alchemy. They have additional syslog facilities including: IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others. Does KAME IPv6 and IPSec have these as well, or are they are creation of Network-Alchemy? jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
does KAME IPv6 and IPSec define additional facilities for syslog? I have been working with IPSec devices from a company called Network-Alchemy. They have additional syslog facilities including: IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others. Does KAME IPv6 and IPSec have these as well, or are they are creation of Network-Alchemy? I believe those additions are by Network-Alchemy. KAME does not modify syslog (are these facilities, by any way, standardized?). itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Itojun, does KAME IPv6 and IPSec define additional facilities for syslog? I have been working with IPSec devices from a company called Network-Alchemy. They have additional syslog facilities including: IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others. Does KAME IPv6 and IPSec have these as well, or are they are creation of Network-Alchemy? jmb To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
does KAME IPv6 and IPSec define additional facilities for syslog? I have been working with IPSec devices from a company called Network-Alchemy. They have additional syslog facilities including: IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others. Does KAME IPv6 and IPSec have these as well, or are they are creation of Network-Alchemy? I believe those additions are by Network-Alchemy. KAME does not modify syslog (are these facilities, by any way, standardized?). itojun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
In message 10335.936082907@localhost, "Jordan K. Hubbard" writes: Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have "kern-developer" still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have "kern-developer" still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... Thanks! It makes the most sense to keep this exactly as it it, except for the files in src/sys/netinet6/ which should move to src/sys/crypto/ if they have crypto in them. Please do not import this until we (JDP!) gets the distribution channels crypto-happy. This is not difficult. itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
On Tue, 31 Aug 1999, Mark Murray wrote: I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. I would prefer src/sys/crypto. I tend to have a lot of kernel-only trees around for my work and the more self-contained they are the better. Moving softupdates into sys/crypto was a good thing (IMHO). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Hmmm. That's a point. I was thinking primarily of the "segregate the crypto" issue, but you're right that this would also put us back to the "bad old days" where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) - Jordan In message 10335.936082907@localhost, "Jordan K. Hubbard" writes: Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have "kern-developer" still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
In message 506.936093482@localhost, "Jordan K. Hubbard" writes: Hmmm. That's a point. I was thinking primarily of the "segregate the crypto" issue, but you're right that this would also put us back to the "bad old days" where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) That's certainly an improvement in that particular battle :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Hmmm. That's a point. I was thinking primarily of the "segregate the crypto" issue, but you're right that this would also put us back to the "bad old days" where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) Yes, this is very pity... Hoping to see more open US export policy in the near future. KAME has "options IPSEC" (framework, authentication and compression) and "options IPSEC_ESP" (encryption) separately defined. Therefore, even if you do not have access to South Africa, you can use AH and IPComp. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : Hmph. I guess common sense wins over ITAR in this case. :) : : That's certainly an improvement in that particular battle :-) Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : Hmph. I guess common sense wins over ITAR in this case. :) : : That's certainly an improvement in that particular battle :-) Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? Nope. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Mark Murray writes : Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. Important thing to remember, and Mark and I have discussed this a little (I think we need a couple more beers when I come to Cape Town next week) there are countries like South Africa, which are not Wassennaar signataries. That makes SA a safe haven for crypto code. grin Geoff. -- Geoff Rehmet, The Internet Solution [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] tel: +27-83-292-5800 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). FreeBSD has the src/crypto directory for this purpose. It works in exactly the same way as src/contrib, but contains code that may get Americans into trouble if they export it, so I maintain a copy in South Africa (on internat.freebsd.org). I'll be very happy to work with you on this one. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). FreeBSD has the src/crypto directory for this purpose. It works in exactly the same way as src/contrib, but contains code that may get Americans into trouble if they export it, so I maintain a copy in South Africa (on internat.freebsd.org). I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). itojun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
In message 10335.936082...@localhost, Jordan K. Hubbard writes: Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have kern-developer still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have kern-developer still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... Thanks! It makes the most sense to keep this exactly as it it, except for the files in src/sys/netinet6/ which should move to src/sys/crypto/ if they have crypto in them. Please do not import this until we (JDP!) gets the distribution channels crypto-happy. This is not difficult. itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
On Tue, 31 Aug 1999, Mark Murray wrote: I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. I would prefer src/sys/crypto. I tend to have a lot of kernel-only trees around for my work and the more self-contained they are the better. Moving softupdates into sys/crypto was a good thing (IMHO). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Hmmm. That's a point. I was thinking primarily of the segregate the crypto issue, but you're right that this would also put us back to the bad old days where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) - Jordan In message 10335.936082...@localhost, Jordan K. Hubbard writes: Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have kern-developer still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
In message 506.936093...@localhost, Jordan K. Hubbard writes: Hmmm. That's a point. I was thinking primarily of the segregate the crypto issue, but you're right that this would also put us back to the bad old days where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) That's certainly an improvement in that particular battle :-) -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Hmmm. That's a point. I was thinking primarily of the segregate the crypto issue, but you're right that this would also put us back to the bad old days where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) Yes, this is very pity... Hoping to see more open US export policy in the near future. KAME has options IPSEC (framework, authentication and compression) and options IPSEC_ESP (encryption) separately defined. Therefore, even if you do not have access to South Africa, you can use AH and IPComp. itojun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
In message 28661.936093...@critter.freebsd.dk Poul-Henning Kamp writes: : Hmph. I guess common sense wins over ITAR in this case. :) : : That's certainly an improvement in that particular battle :-) Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
In message 28661.936093...@critter.freebsd.dk Poul-Henning Kamp writes: : Hmph. I guess common sense wins over ITAR in this case. :) : : That's certainly an improvement in that particular battle :-) Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? Nope. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Mark Murray writes : Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. Important thing to remember, and Mark and I have discussed this a little (I think we need a couple more beers when I come to Cape Town next week) there are countries like South Africa, which are not Wassennaar signataries. That makes SA a safe haven for crypto code. grin Geoff. -- Geoff Rehmet, The Internet Solution geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org tel: +27-83-292-5800 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
KAME IPv6 and freebsd
I heard that, some of you, got confused by recent news about additional NetBSD-core guys (me). The above fact does not change anything about KAME-FreeBSD relationship (I can only speak for KAME side though), because: - KAME project's goal is to provide IPv6/IPsec reference code to *BSD, so we of course continue to work on KAME/FreeBSD, KAME/BSDI, and KAME/NetBSD. We are trying to support KAME/OpenBSD (so that no major BSDs are left out from our support list). - KAME project is NOT itojun's personal project. It involves 8 core KAME guys and several other people. There are 3 KAME guys (incl. me) who has committer access to FreeBSD repository. So, the fact I became one of NetBSD-core does not mean anything to KAME project. - NetBSD merged KAME stack earlier because NetBSD have more strict "feature freeze" policy than FreeBSD (if I don't import now KAME will not be inclduded in NetBSD 1.5). FreeBSD has been waiting for unified-ipv6 to experience less "jumbo import" during IPv6 merge. And then, FreeBSD-IPv6 plan. Now (as attached), unified-ipv6 effort has settled down into KAME. so it should be okay to merge KAME (= unified-ipv6) into FreeBSD-current. There may be some changes that may trouble you during the first period of merging, but I think FreeBSD and KAME guys can work those technical issues out. KAME side is, I think, quite ready to merge. KAME side needs FreeBSD-core's word like "okay, go ahead", and direction about merger of IPsec part. itojun Bah, so FreeBSD will be InSecureBSD ? Well, so long as the ITAR bear stands around making grizzly noises at people, it seems. I wouldn't count on that. As far as I can tell, what's holding KAME integration up is the fact that they're not done merging with INRIA yet. A news about NRL/INRIA/KAME merging (unified-ipv6). unified-ipv6 project has been in big trouble with manpower, design differences. Recently situations changed for all of us so here's the decision we have made. NRL decided to concentrates on IPsec (because in US not much interest in IPv6 than IPsec - people in US are lucky about IPv4 address space, it seems). INRIA will be doing future researches on top of KAME code. KAME agreed to add some knobs that helps INRIA to do their experiment. So, it is planned that KAME will have an alias: "unified-ipv6". KAME team is trying to ship KAME/OpenBSD and KAME/BSDI4 during this month or next month (September). KAME September 30th STABLE kit will officially have "unified-ipv6" alias on it. It is now okay to merge KAME code into FreeBSD, I believe. If you do not feel ready, I'll be visiting FreeBSDCon so let's talk about it there (but will cause 2 month delay from now). The biggest problem is how to keep mutiple repositories in sync. KAME (= unified-ipv6) code shares most of IPv6 code among *BSD platforms. If FreeBSD repository is modified after import, and that conflicts with content in KAME repository, we can't merge that back in. So I would like to suggest FreeBSD project to refrain from changing IPv6 part too much, for certain amount of time (*). Rather, please send diffs to KAME. Once that happens, I'm more than happy to continue to lean on Justice Maryln Patel's decision on crypto as free speach in the S.F. Bay Area region. We've already talked to our lawyer, he said it looked legit to him, and so we've been shipping crypto on our CDs for over a year now. I even announced it back then, to almost no audience reaction whatsoever. It seems that people like to get more excited about the prospect of something being closed than it being opened up. :) It now happened, so please contact Mr. Patel:-) KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). itojun (*) As a side note: actually, KAME and unified-ipv6 has been experiencing big trouble sharing IPv6 code among *BSD, due to FreeBSD's variable renaming like ifa_list (ifa_link on others) or time_second (why FreeBSD couldn't reuse time.tv_sec to hold this? I don't get it). I'd like propose to fix those back to more standard ones (ifa_link or time.tv_sec) for portability among *BSD. If you a
KAME IPv6 and freebsd
I heard that, some of you, got confused by recent news about additional NetBSD-core guys (me). The above fact does not change anything about KAME-FreeBSD relationship (I can only speak for KAME side though), because: - KAME project's goal is to provide IPv6/IPsec reference code to *BSD, so we of course continue to work on KAME/FreeBSD, KAME/BSDI, and KAME/NetBSD. We are trying to support KAME/OpenBSD (so that no major BSDs are left out from our support list). - KAME project is NOT itojun's personal project. It involves 8 core KAME guys and several other people. There are 3 KAME guys (incl. me) who has committer access to FreeBSD repository. So, the fact I became one of NetBSD-core does not mean anything to KAME project. - NetBSD merged KAME stack earlier because NetBSD have more strict feature freeze policy than FreeBSD (if I don't import now KAME will not be inclduded in NetBSD 1.5). FreeBSD has been waiting for unified-ipv6 to experience less jumbo import during IPv6 merge. And then, FreeBSD-IPv6 plan. Now (as attached), unified-ipv6 effort has settled down into KAME. so it should be okay to merge KAME (= unified-ipv6) into FreeBSD-current. There may be some changes that may trouble you during the first period of merging, but I think FreeBSD and KAME guys can work those technical issues out. KAME side is, I think, quite ready to merge. KAME side needs FreeBSD-core's word like okay, go ahead, and direction about merger of IPsec part. itojun ---BeginMessage--- Bah, so FreeBSD will be InSecureBSD ? Well, so long as the ITAR bear stands around making grizzly noises at people, it seems. I wouldn't count on that. As far as I can tell, what's holding KAME integration up is the fact that they're not done merging with INRIA yet. A news about NRL/INRIA/KAME merging (unified-ipv6). unified-ipv6 project has been in big trouble with manpower, design differences. Recently situations changed for all of us so here's the decision we have made. NRL decided to concentrates on IPsec (because in US not much interest in IPv6 than IPsec - people in US are lucky about IPv4 address space, it seems). INRIA will be doing future researches on top of KAME code. KAME agreed to add some knobs that helps INRIA to do their experiment. So, it is planned that KAME will have an alias: unified-ipv6. KAME team is trying to ship KAME/OpenBSD and KAME/BSDI4 during this month or next month (September). KAME September 30th STABLE kit will officially have unified-ipv6 alias on it. It is now okay to merge KAME code into FreeBSD, I believe. If you do not feel ready, I'll be visiting FreeBSDCon so let's talk about it there (but will cause 2 month delay from now). The biggest problem is how to keep mutiple repositories in sync. KAME (= unified-ipv6) code shares most of IPv6 code among *BSD platforms. If FreeBSD repository is modified after import, and that conflicts with content in KAME repository, we can't merge that back in. So I would like to suggest FreeBSD project to refrain from changing IPv6 part too much, for certain amount of time (*). Rather, please send diffs to KAME. Once that happens, I'm more than happy to continue to lean on Justice Maryln Patel's decision on crypto as free speach in the S.F. Bay Area region. We've already talked to our lawyer, he said it looked legit to him, and so we've been shipping crypto on our CDs for over a year now. I even announced it back then, to almost no audience reaction whatsoever. It seems that people like to get more excited about the prospect of something being closed than it being opened up. :) It now happened, so please contact Mr. Patel:-) KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). itojun (*) As a side note: actually, KAME and unified-ipv6 has been experiencing big trouble sharing IPv6 code among *BSD, due to FreeBSD's variable renaming like ifa_list (ifa_link on others) or time_second (why FreeBSD couldn't reuse time.tv_sec to hold this? I don't get it). I'd like propose to fix those back to more standard ones (ifa_link or time.tv_sec) for portability among *BSD. If you are okay, those changes will come with FreeBSD
