Re: KAME integration and plans
Kris Kennaway wrote: In this vein, I'd like to suggest a new "hands-off" policy of not committing gratuitous changes to KAME-derived code, including manpage changes, unless: a) The commit is required for operation on FreeBSD (in which case it's not really gratuitous) I'd like to commit this: --- stf.4 2000/07/04 16:39:23 1.4 +++ stf.4 2000/07/11 13:44:47 @@ -36,7 +36,7 @@ .Nd .Tn 6to4 tunnel interface .Sh SYNOPSIS -.Cd "pseudo-device stf" +.Cd "pseudo-device gif" .Sh DESCRIPTION The .Nm 'pseudo-device stf' gives an error, stf lives in the gif driver, so this is required really. Is that ok? Is there anyone at KAME I should send this to as well? Sheldon Hearn will be taking care of passing the manpage diffs back to KAME. ah... right. I guess that answers my question. :-) Sheldon - you can commit this yourself if you want, or shall I do it and you just take care of passing it back to KAME? It's releated to PR 19163 by the way. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: KAME integration and plans
On Tue, 11 Jul 2000 14:56:35 +0100, Ben Smithurst wrote: 'pseudo-device stf' gives an error, stf lives in the gif driver, so this is required really. Is that ok? Is there anyone at KAME I should send this to as well? I'm interested to see how the KAME folks react to our chucking out the pseudo-device keyword from config(8). :-) Sheldon Hearn will be taking care of passing the manpage diffs back to KAME. ah... right. I guess that answers my question. :-) Sheldon - you can commit this yourself if you want, or shall I do it and you just take care of passing it back to KAME? It's releated to PR 19163 by the way. For now, I'll be looking at passing back to the KAME folks all those fixes that this pending merge will blow away. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
Sheldon Hearn wrote: On Tue, 11 Jul 2000 14:56:35 +0100, Ben Smithurst wrote: 'pseudo-device stf' gives an error, stf lives in the gif driver, so this is required really. Is that ok? Is there anyone at KAME I should send this to as well? I'm interested to see how the KAME folks react to our chucking out the pseudo-device keyword from config(8). :-) Ah, good point... I did my test on -stable where pseudo-device still exists. I'll wait for a while for this one then. There's another PR open on this problem, which asmodai is looking at (18852). -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: KAME integration and plans
On Tue, 11 Jul 2000 14:56:35 +0100 Ben Smithurst [EMAIL PROTECTED] said: ben 'pseudo-device stf' gives an error, stf lives in the gif driver, so this ben is required really. Is that ok? Is there anyone at KAME I should send ben this to as well? No. Before merging latest KAME, that is true. In that days, stf was quick hack version of gif. But, stf is NOT gif but stf, now. My config contains: device stf # 6to4 IPv6 over IPv4 encapsulation -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
Hajimu UMEMOTO wrote: On Tue, 11 Jul 2000 14:56:35 +0100 Ben Smithurst [EMAIL PROTECTED] said: ben 'pseudo-device stf' gives an error, stf lives in the gif driver, so this ben is required really. Is that ok? Is there anyone at KAME I should send ben this to as well? No. Before merging latest KAME, that is true. In that days, stf was quick hack version of gif. But, stf is NOT gif but stf, now. My config contains: device stf # 6to4 IPv6 over IPv4 encapsulation Ok. I guess all that needs doing is s/pseudo-device/device/ in the SYNOPSIS then. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: KAME integration and plans
On Tue, 11 Jul 2000, Ben Smithurst wrote: I'd like to commit this: --- stf.4 2000/07/04 16:39:23 1.4 +++ stf.4 2000/07/11 13:44:47 @@ -36,7 +36,7 @@ .Nd .Tn 6to4 tunnel interface .Sh SYNOPSIS -.Cd "pseudo-device stf" +.Cd "pseudo-device gif" .Sh DESCRIPTION The .Nm 'pseudo-device stf' gives an error, stf lives in the gif driver, so this is required really. Is that ok? Is there anyone at KAME I should send this to as well? Um, "device stf" certainly does work. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
Kris Kennaway wrote: On Tue, 11 Jul 2000, Ben Smithurst wrote: 'pseudo-device stf' gives an error, stf lives in the gif driver, so this is required really. Is that ok? Is there anyone at KAME I should send this to as well? Um, "device stf" certainly does work. Ah. I'm using -STABLE here... AFAICT you still need 'pseudo-device gif' there. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: KAME integration and plans
Could you mention the locations (as in a set of paths) that are hands-off? I'll generate a list and put it somewhere (in the tree?) Good idea. To be honest, I was more thinking of the heads up message. But it was suggested to add it to the readme in netinet6/ Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
KAME integration and plans
As itojun has already posted, we are in the process of updating the KAME IPv6/IPSEC code in FreeBSD to the latest KAME sources. In importing the latest KAME code, we are not being too concerned about whitespace or cosmetic diffs, unifdef'ing __NetBSD__ sections (at least in userland) and so forth. The reason for this is that KAME is externally maintained code, and so cosmetic differences in FreeBSD needlessly complicate the diffs and really make life harder for merging. The KAME team already have a difficult enough job in maintaining and developing the code on 11 different BSD releases without us making life more difficult for them by committing unneccessary code changes to FreeBSD. In this vein, I'd like to suggest a new "hands-off" policy of not committing gratuitous changes to KAME-derived code, including manpage changes, unless: a) The commit is required for operation on FreeBSD (in which case it's not really gratuitous) b) The commit is suitable for the other platforms KAME supports as well, and is submitted back to KAME to be merged into their master repo. If there are legitimate concerns with KAME code the place to get them fixed is upstream, not in FreeBSD. For example, the "hard sentence break" manpage sweeps should have been submitted back to KAME, and the "remove unneeded #includes" should not have touched the KAME code at all since it creates gratuitous diffs for no functional change. X years down the line if the KAME project disbands, we can do the FreeBSD style cleanups then. At the moment I am not bothering to merge in gratuitous FreeBSD changes to things like manpages, because we want to get this code into -current and tested as quickly as possible. Sheldon Hearn will be taking care of passing the manpage diffs back to KAME. I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any problems, so this means we need everyone who is capable of doing so to stress the new code as much as possible. IMO we *really* need to get this into 4.1 despite the relatively short testing cycle, for the simple reason that the newer code is much more functional, and in particular supports the racoon IKE daemon for automatic management of IPSEFC security associations (i.e. manually-keyed SAs are no longer required) - this is already in ports. This is important for interoperability with other IPSEC implementations. I also would quite like to see ALTQ brought in - I have had lots of support for this and so far no objections - although I forgot to ask itojun not to unifdef that code before it was committed :-(. Perhaps if he has time he'll commit that as well. Userland binaries are not yet fully committed: the older binaries may not work corectly with the new kernel code. Anyone wanting to play with this stuff to help test it should check out www.freenet6.net, who provide a very simple way to establish a tunnel to the 6bone. Documentation is available on www.kame.net and related links. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
In message [EMAIL PROTECTED], Kri s Kennaway writes: I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any problems, I'm sorry, but isn't that a tad fast, considering the scope of these changes ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
On Wed, 5 Jul 2000, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Kri s Kennaway writes: I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any problems, I'm sorry, but isn't that a tad fast, considering the scope of these changes ? I forgot to mention that I discussed this with Jordan at Usenix and (unless I'm mistaken) he okayed the general plan. These changes should only impact ipv6 and ipsec, with the exception of the DNS resolver code which I'm still unsure about merging (even though it's been well tested by KAME users, there remains the possibility of breakage for ipv4 resolution if there are undiscovered bugs) The bottom line is that we *need* the updated IPSEC code if FreeBSD is to be a viable IPSEC platform. At the moment it's really only usable for interoperating with other FreeBSD machines because in the real world people use an IKE daemon, which the older (currently in 4.0) code does not support. Delaying this another 3 months for 4.2 is, IMO, far too long to wait if we're going to be competitive in the IPSEC arena. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
On 5/07, Kris Kennaway wrote: | I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any | problems, so this means we need everyone who is capable of doing so to | stress the new code as much as possible. IMO we *really* need to get this | into 4.1 despite the relatively short testing cycle, for the simple reason | that the newer code is much more functional, and in particular supports | the racoon IKE daemon for automatic management of IPSEFC security | associations (i.e. manually-keyed SAs are no longer required) - this is | already in ports. This is important for interoperability with other IPSEC | implementations. How hard would it be to use IPSEC with *.freebsd.org machines (at least www.freebsd.org)? This would be a good test. Of course, IPSEC should not be required ;) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
On Wed, 5 Jul 2000, Samuel Tardieu wrote: On 5/07, Kris Kennaway wrote: | I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any | problems, so this means we need everyone who is capable of doing so to | stress the new code as much as possible. IMO we *really* need to get this | into 4.1 despite the relatively short testing cycle, for the simple reason | that the newer code is much more functional, and in particular supports | the racoon IKE daemon for automatic management of IPSEFC security | associations (i.e. manually-keyed SAs are no longer required) - this is | already in ports. This is important for interoperability with other IPSEC | implementations. How hard would it be to use IPSEC with *.freebsd.org machines (at least www.freebsd.org)? This would be a good test. Of course, IPSEC should not be required ;) Well, IPSEC isn't configured at all on those machines right now, and it's probably not the best place to test from. But by all means if you have the capability to test the new racoon port, especially interoperating it with other IPSEC implementations (subject to what KAME is known to support) please do so. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
These changes should only impact ipv6 and ipsec, with the exception of the DNS resolver code which I'm still unsure about merging (even though it's been well tested by KAME users, there remains the possibility of breakage for ipv4 resolution if there are undiscovered bugs) actually, I've touched sys/sys/mbuf.h. there should be no behavior change if you do not use any of the following items: - ipsec - ipv6, inclding stf interface - gif interface gif can be used for v4 over v4. due to the change mentioned above, and recent checksum offloading stuff, some of network driver code may need fixes like below. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/lnc/if_lnc.c.diff?r1=1.78r2=1.79 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vx/if_vx.c.diff?r1=1.27r2=1.28 (if a driver sets M_PKTHDR flag manually, it needs checking) itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
Could you mention the locations (as in a set of paths) that are hands-off? Nick On Wed, 5 Jul 2000, Kris Kennaway wrote: As itojun has already posted, we are in the process of updating the KAME IPv6/IPSEC code in FreeBSD to the latest KAME sources. In importing the latest KAME code, we are not being too concerned about whitespace or cosmetic diffs, unifdef'ing __NetBSD__ sections (at least in userland) and so forth. The reason for this is that KAME is externally maintained code, and so cosmetic differences in FreeBSD needlessly complicate the diffs and really make life harder for merging. The KAME team already have a difficult enough job in maintaining and developing the code on 11 different BSD releases without us making life more difficult for them by committing unneccessary code changes to FreeBSD. In this vein, I'd like to suggest a new "hands-off" policy of not committing gratuitous changes to KAME-derived code, including manpage changes, unless: a) The commit is required for operation on FreeBSD (in which case it's not really gratuitous) b) The commit is suitable for the other platforms KAME supports as well, and is submitted back to KAME to be merged into their master repo. If there are legitimate concerns with KAME code the place to get them fixed is upstream, not in FreeBSD. For example, the "hard sentence break" manpage sweeps should have been submitted back to KAME, and the "remove unneeded #includes" should not have touched the KAME code at all since it creates gratuitous diffs for no functional change. X years down the line if the KAME project disbands, we can do the FreeBSD style cleanups then. At the moment I am not bothering to merge in gratuitous FreeBSD changes to things like manpages, because we want to get this code into -current and tested as quickly as possible. Sheldon Hearn will be taking care of passing the manpage diffs back to KAME. I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any problems, so this means we need everyone who is capable of doing so to stress the new code as much as possible. IMO we *really* need to get this into 4.1 despite the relatively short testing cycle, for the simple reason that the newer code is much more functional, and in particular supports the racoon IKE daemon for automatic management of IPSEFC security associations (i.e. manually-keyed SAs are no longer required) - this is already in ports. This is important for interoperability with other IPSEC implementations. I also would quite like to see ALTQ brought in - I have had lots of support for this and so far no objections - although I forgot to ask itojun not to unifdef that code before it was committed :-(. Perhaps if he has time he'll commit that as well. Userland binaries are not yet fully committed: the older binaries may not work corectly with the new kernel code. Anyone wanting to play with this stuff to help test it should check out www.freenet6.net, who provide a very simple way to establish a tunnel to the 6bone. Documentation is available on www.kame.net and related links. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
Could you mention the locations (as in a set of paths) that are hands-off? thanks for your understanding, will try to list those and put the list into sys/netinet6/README. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
This is great news -- one of the big hangups in our interop testing at NAI Labs was the like of IKE on FreeBSD. I notice that right now racoon is a port -- assuming this interpretation is correct, are their any plans to integrate racoon as a base system component? As you point out, without IKE, FreeBSD's IPsec implementation is effectively useless for cross-platform communication due to the number of frobs in SA configuration. I also look forward to the rapid MFC'ing, assuming that the code works :-). Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
This is great news -- one of the big hangups in our interop testing at NAI Labs was the like of IKE on FreeBSD. I notice that right now racoon is a port -- assuming this interpretation is correct, are their any plans to integrate racoon as a base system component? As you point out, without IKE, FreeBSD's IPsec implementation is effectively useless for cross-platform communication due to the number of frobs in SA configuration. I also look forward to the rapid MFC'ing, assuming that the code works :-). this is because we expect to have so many many changes/improvements in racoon - once we put racoon into base tree, we need to be much more careful about backward-compatibility in config file, for example. also, we need to improve kernel policy management for socket-based policy, and process-to-process policy inheritance. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
On Wed, 5 Jul 2000, Nick Hibma wrote: Could you mention the locations (as in a set of paths) that are hands-off? I'll generate a list and put it somewhere (in the tree?) Good idea. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
On Wed, 5 Jul 2000, Robert Watson wrote: This is great news -- one of the big hangups in our interop testing at NAI Labs was the like of IKE on FreeBSD. I notice that right now racoon is a port -- assuming this interpretation is correct, are their any plans to integrate racoon as a base system component? As you point out, without IKE, FreeBSD's IPsec implementation is effectively useless for cross-platform communication due to the number of frobs in SA configuration. I also look forward to the rapid MFC'ing, assuming that the code works :-). racoon was not imported because it is still a rapidly changing target..perhaps once development slows down a bit we can import it (NetBSD also have it in ports) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
