Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 68066
Summary: | CIPE update to 1.5.4 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Muralidhar Ganga <gmurali> |
Component: | cipe | Assignee: | Nalin Dahyabhai <nalin> |
Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | chris.ricker, dr, eric-bugs, ivo, jdouglas, jgiglio, k.georgiou, laroche, matt, mharris, olaf, ralston, tedkaz, wtogami |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-06-04 22:36:35 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 67218, 78238, 79579, 100644 | ||
Attachments: |
Description
Muralidhar Ganga
2002-07-06 01:18:43 UTC
I'd second this. CIPE 1.5.4 is the current stable release, and it includes lots of useful features which aren't in the old 1.4 series. pkcipe makes usage of cipe with dynamic IP addresses much simpler and more secure (uses public key exchange to authenticate and then configure each tunnel end, rather than configuration based on IP addresses of the tunnel ends). 1.5.4 supports native IPv6; I've never gotten CIPE 1.4 to do IPv6 tunnels. There are also some more esoteric changes (1.5 supports ethernet bridging, for example) that are less likely to be useful, but at least pkcipe and IPv6 are essential for some of my hosts It's been almost 5 months since this RFE was opened, and cipe 1.5.4 isn't even in Rawhide. Could we *please* at least have a status update? I mean, if there's a blocker here, or something else which would make moving to 1.5.4 difficult, at least let people know; just don't let the bug sit at status NEW (with no comments from the assignee) for 5 months... If you need motivation, note that Red Hat gets regularly bashed on the cipe-l mailing list for still shipping cipe 1.4.5. :p I third or fourth this. CIPE is an immensely useful tool, and it would be even more useful if it supported IPv6. I really could care less about the somewhat more sophisticated key management allowed by pkcipe, but the other features (including some security enhancements) would be most welcome. *** Bug 78238 has been marked as a duplicate of this bug. *** *** Bug 75754 has been marked as a duplicate of this bug. *** This bug needs to be assigned to the right person, whoever is working with cipe to get the latest. Anyone know whom to be assign ? Argh. Phoebe (at least the first revision) still contains cipe-1.4.5! I repeat my previous request for a status update. Nalin, could you please at least acknowledge that *someone* at Red Hat is aware of this bug? Free drinks and grog for Nalin in NY area on me if we get 1.5.4 soon. I've asked a few people about this, and they believe that cipe 1.5.x contains changes that break the ABI used in 1.4. If this is true (which I have not had a chance to verify), then it would mean clients using 1.4 which connect to a 1.5 server, or vice versa would be incompatible with each other. Perhaps we can investigate if the ABI is indeed broken or not with respect to cipe 1.4 in the new version. If this would be an incompatible change, perhaps we can consider backporting bug fixes and improvements. Do any of you know of specific improvements and/or features the new release brings off hand? If you could itemize some of the important things, it might help prioritize investigation of what might be needed if we were to consider a backport. I can't speak for the other ~10 people who've been requesting this, but for me CIPE 1.5.x is required in many situations because: 1. It supports IPv6, and 1.4.x doesn't. I've never gotten 1.4.x to do reliable IPv6 tunnels, and I don't think it's even supposed to support them. v6 Just Works with 1.5.x 2. 1.5.x supports what it calls PKCIPE -- certificate-based authentication of the two ends to each other. 1.4.x only supports shared-private-key + IP address as authentication. PKCIPE probably has security advantages (migration from shared private key to certificate schemes usually does) but more importantly, it makes CIPE usable with dynamic IPs, or with NAT, in configurations where CIPE 1.4.x simply will not work. PKCIPE can be used if both ends are dynamic; CIPE 1.4.x requires one end to be static. PKCIPE conceptually should be usable if both ends are NAT'ed, while CIPE 1.4.x would fail, I would think (the "both ends NAT'ed" is not a configuration I've personally needed to deal with, so that one I've not personally verified. The "both ends dynamic IP" I have...) Those are the two reasons which matter to me, or to clients of mine. The IPv6 support matters most for me, but I'd guess that for most Red Hat customers the PKCIPE support is probably more useful.... My clients who've had to upgrade have mostly needed 1.5.x for PKCIPE, though a couple have needed v6. A couple of other factors which might also matter to some: 3. CIPE 1.5.x supports Ethernet bridging over CIPE, while 1.4.x doesn't. I don't currently use / need this, but others might. 4. CIPE 1.4.x is no longer supported upstream. Questions, bug reports, etc., are greeted with an "upgrade and then we'll talk" response. I'm a little confused by your talk about ABI changing. I'm not sure why you'd care if the ABI changed. Upgrading the kernel driver to 1.5.x CIPE will require the CIPE userland upgrade as well, but I don't see that as being any different than, say, XFree86 requiring specific DRI from the kernel. If RHL upgrades both the driver and the userland, then installs still work.... I'd think what matters is if the CIPE network protocol has changed, meaning that 1.4.x clients can't talk to 1.5.x servers or vice-versa. CIPE 1.5.x does add a new version of the network protocol, but I think it still supports the old version. I can double-check that in a few hours to see if 1.5.x clients can connect with 1.4.x servers and vice-versa. I'm neither the cipe maintainer, userland side nor kernel side, but I'm responding with my own thoughts, since you did request that someone respond on the mailing list. Several of the points you bring up are perhaps useful, at least to some small portion of the Red Hat userbase likely. I don't believe that they are necessarily generally useful to the majority of users though, so upgrading cipe in a future release is likely to be frowned upon if complete compatibility can't be maintained. I suspect that this is the reason it has not been done so far, however I don't have any direct communication of that. >I'm a little confused by your talk about ABI changing. I'm not sure why you'd >care if the ABI changed. Upgrading the kernel driver to 1.5.x CIPE will require >the CIPE userland upgrade as well, but I don't see that as being any different >than, say, XFree86 requiring specific DRI from the kernel. If RHL upgrades both >the driver and the userland, then installs still work.... That is a question that arjan and/or nalin would have to answer. It would be possible to make the kernel packages Require: cipe >= 1.5 or whatever to enforce the update of the cipe package in a new release. This may cause problems however if a cipe interface is actually being used when the upgrade occurs. The new utilities would likely be expected by us to be able to bring a 1.4 interface down, which might be running after the update (or during it), however that would only likely be a requirement if it was for an erratum release. Again, I can not comment authoritatively on this though. Just giving my opinion based on knowledge of our general policies on things. >I'd think what matters is if the CIPE network protocol has changed, meaning >that 1.4.x clients can't talk to 1.5.x servers or vice-versa. CIPE 1.5.x >does add a new version of the network protocol, but I think it still >supports the old version. I can double-check that in a few hours to see if >1.5.x clients can connect with 1.4.x servers and vice-versa. If 1.5.x and 1.4.x can not communicate freely in both directions in every combination, I'm almost 100% certain that we would never consider upgrading cipe, as it would break existing working setups for people, or would require everyone upgrade all systems wether they want to or not. If we couldn't make the change cleanly, it is at least theoretically possible that if there is large enough customer demand, we could consider backporting safe fixes and feature enhancements that do not break compatibility. If not, we also offer consulting engineering services that customers can use to affect product priorities, etc. Anyhow, this is all a lot of speculation on my part for now. If you find out about the compatibility issues, please update the report, and I will have a peek myself into it, and chat with other developers. Hope this helps. There are a few versions of the CIPE protocol. The default for 1.5.4 is version 3, which is the same version as in 1.4.x. 1.5.4 compiled with version 3 (./configure --enable-protocol=3, or just accept defaults) is interacting with RHL 8.0 just fine. I'm not sure what happens with --enable-protocol=4 (on 1.5.4) interacting with the 1.4.x version in RHL 8.0. I'll try to test that as well, but that'll probably be a couple of days. There have been interoperability issues between CIPE versions, but they were early in the CIPE release history, and they were caused by changes in the key format, not by protocol changes.... 1.4.0 and later are all fine in terms of key exchange, AFAIK. FWIW, I was not expecting this to be resolved by an errata. This sort of change should be done with a new release of RHL (such as the upcoming one ;-), which at least removes the complexity of worrying about ABI compatibility. A word from the CIPE author: comment 11 is right. CIPE 1.5 is compatible with 1.4 on the wire if configured for protocol 3. (To use features like Ethernet bridging you need protocol 4, which is incompatible[*].) The ABI between kernel and user part is not compatible but that doesn't matter, as nothing but ciped uses it. In short: an upgrade should not break anything. [*] but you can run both versions in parallel. Thanks Olaf. That should provide our engineers with enough information IMHO to decide wether or not we should update to cipe 1.5.x in a future OS release. If nobody responds further here in this enhancement request, don't assume that nobody has read it. It is safe to assume that the feature request is still open to consideration, but no sense in updating this report until it is decided to make the update. Until then, consider it to be up for future consideration. Hope this helps. with ./configure --enable-protocol=4 both version 3 and 4 are in the code. the actual binary is split into two seperate executables and modules. Protocol 3 uses the same ciped-cb deamon/cipcb module and protocol 4 uses ciped-db deamon/cipdb module. I have existing tunnels working with 1.4 and 1.5 and new tunnels working with other 1.5 at the same time. I would also like to see an upgrade, as I'm currently setting up a CIPE VPN (using RHL9) and being unable to route IPv6 over it... need to embed GRE tunnels within the VPN. Tunnels in Tunnels... :-/ Kernel patches against 2.4.22-pre7 attached to this bug entry. This provide cleaned up versions of cipe 1.5.4 with all relevant Red Hat cipe patches from 1.4.6 applied (and VERSION_MAGIC check removed). Created attachment 93149 [details]
Patch to add cipe v3 tree
This patch adds a source tree for cipe protocol 3, version 1.5.4, with Red Hat
patches and VERSION_MAGIC check removed. Use CONFIG_CIPE3=m to build the module
from this tree.
Created attachment 93150 [details]
Patch to add cipe4 support
This patch adds a source tree for cipe protocol 4, version 1.5.4, with Red Hat
patches included and VERSION_MAGIC check removed. Use CONFIG_CIPE4=m to build
the module from this tree.
Created attachment 93151 [details]
Fixed version of Patch10010 for cipe3/cipe4 split.
This is a fixed version of Patch10010 to reflect the new cipe patchset.
Created attachment 93152 [details]
This is a fixed version of Patch5000, to reflect the cipe3/cipe4 split.
This is a fixed version of Patch5000, to go with the new cipe 1.5.4 patchset.
cipe is neither in RHEL nor Fedora anymore, so I guess this case can be closed now. It's beating a dead horse. |