Talking about signal termination is like opening a can of worms. This is a HUGE subject that is difficult to summarize in just a couple hundred words. Therefore, I won't. I am going to leave a huge amount of stuff out of this answer. But I will also give you a big warning: There is much misinformation about terminating resistors on the net. In fact, I would say that most of what's found on the net is wrong or misleading. Some day I'll write up something big and post it to my blog, but not today.
The first thing to note is that the resistor value to use for your termination must be related to your trace impedance. Most of the time the resistor value is the same as your trace impedance. If you don't know what the trace impedance is then you should figure it out. There are many online impedance calculators available. A Google search will bring up dozens more.
Most PCB traces have an impedance from 40 to 120 ohms, which is why you found that a 1k termination resistor did almost nothing and a 100-ish ohm resistor was much better.
There are many types of termination, but we can roughly put them into two categories: Source and End termination. Source termination is at the driver, end termination is at the far end. Within each category, there are many types of termination. Each type is best for different uses, with no one type good for everything.
Your termination, a single resistor to ground at the far end, is actually not a very good. In fact, it's wrong. People do it, but it isn't ideal. Ideally that resistor would go to a different power rail at half of your power rail. So if the I/O voltage is 3.3v then that resistor will not go to GND, but another power rail at half of 3.3v (a.k.a. 1.65v). The voltage regulator for this rail has to be special because it needs to source AND sink current, where most regulators only source current. Regulators that work for this use will mention something about termination in the first page of the datasheet.
The big problem with most end-termination is that they consume lots of current. There is a reason for this, but I won't go into it. For low-current use we must look at source termination. The easiest and most common form of source termination is a simple series resistor at the output of the driver. The value of this resistor is the same as the trace impedance.
Source termination works differently than end termination, but the net effect is the same. It works by controlling signal reflections, not preventing the reflections in the first place. Because of this, it only works if a driver output is feeding a single load. If there are multiple loads then something else should be done (like using end termination or multiple source termination resistors). The huge benefit of source termination is that it does not load down your driver like end termination does.
I said before that your series resistor for source termination must be located at the driver, and it must have the same value as your trace impedance. That was an oversimplification. There is one important detail to know about this. Most drivers have some resistance on it's output. That resistance is usually in the 10-30 ohm range. The sum of the output resistance and your resistor must equal your trace impedance. Let's say that your trace is 50 ohms, and your driver has 20 ohms. In this case your resistor would be 30 ohms since 30+20=50. If the datasheets do not say what the output impedance/resistance of the driver is then you can assume it to be 20 ohms-- then look at the signals on the PCB and see if it needs to be adjusted.
Another important thing: when you look at these signals on an o-scope you MUST probe at the receiver. Probing anywhere else will likely give you a distorted waveform and trick you into thinking that things are worse than they really are. Also, make sure that your ground clip is as short as possible.
Conclusion: Switch to source termination with a 33 to 50 ohm resistor and you should be fine. The usual caveats apply.
Background Information
I have used CAN a few times now for multiple devices distributed over a physically small area, like within a few 10s of meters. In each case, the CAN bus was internal to the system and we could specify exactly what the protocol over CAN would be. None
of these systems had to, for example, interface with OBDII, NMEA2000, etc, where a specific protocol was already defined. One case was a large industrial machine that required lots of distributed sensors and actuators. The outside world interface just dealt with the overall operation of the machine. How the controller got the sensor information and caused the actuators to do stuff was a internal implementation choice that we happened to use CAN for. In another case, a company needed a good way for their customers to control multiple (up to a few dozen) of the gizmos they make within a single larger system. In this case we specified CAN as one communication means and documented the protocol. This protocol would be implemented by the controller of this system, but not surfaced to the end customer which bought this system as a whole and communicated with it thru different means at a higher level.
The EmCan solution
I have converged on a way of dealing with this over several implementations. I am now in the middle of two more such implementations, and this time I decided to use the previous experience to create a formal spec for a infrastructure layer immediately above CAN. CAN is a well designed protocol as far as it goes, and is directly implemented in a number of microcontrollers nowadays. It seems a natural way to connect multiple little devices over a limited physical distance as long as the data rate isn't too high. Basically, it can do everything you probably would have used RS-485 for 20 years ago, except that more protocol layers are specified, the specification makes sense, and hardware implementations are available built into low cost microcontrollers.
The result of this is what I call EmCan (EMbed CAN). I am slowly filling out the formal protocol specification as I migrate code from the previous implementations, generalize the concepts a bit, and make re-usable firmware modules where the EmCan protocol code can be used without change accross a variety of projects. I'm not really ready to officially publish the spec yet and provide the reference implementations, but you can look at what is there to see where things are heading. The current document is a work in progress, as it itself says.
So far I have PIC 18 and dsPIC 33 implementations of the EmCan device side, a stripped down host implementation for PIC 18, and a more full (more things handled locally) implementation for the dsPIC 33. Everything documented in the current version is implemented and seems to be working. I am working on the byte stream interface right now. I did this before in one of the previous systems, but it was more tied into the application and not a nice separable layer like EmCan.
The issue with a switched load
I think trying to switch the CAN bus with FETs or analog switches is a really bad idea. The main reason for the bit rate versus length tradeoff is not the total resistance of the cable, but the round trip propagation. Look at how CAN detects collisions, and you will see this mechanism assumes signal propagation from one end to the other within a fraction of a bit time. The CAN bus needs to be kept a transmission line. For most implementations, such as when using the common MCP2551 bus driver, the characteristic impedance should be close to 120 Ω. That means a 120 Ω resistor at each end of the bus, so any point on the bus looks like a 60 Ω load.
How EmCan fixes this
EmCan solves the node address problem without requiring special hardware. For details, see the EmCan spec, but basically, each node has a globally unique 7 byte ID. Each node periodically requests a bus address and sends this ID. The collision detection mechanism will guarantee that the bus master sees only one of these requests even if multiple nodes send a address request at the same time. The bus master sends a address assignment message that includes the 7 byte ID and the assigned address, so at most one single node is assigned a new address at a time.
If you are interested in this concept and are willing to discuss details of your system, talk to me. My biggest fear right now is specifying something that will be awkward later or prohibit certain usage that I hadn't considered. Having another implementation in progress as the spec is being finalized would be good for spec development and to test out the reference implemenation if you plan to implement it on Microchip PICs.
Best Answer
The intent of the resistors at each end of the bus is to control transients due to time delays. The bus needs to be terminated with its characteristic impedance at each end.
However if the bus is only 6 feet long I would expect your implementation with a 60 ohm resistor in the middle to work. I expect you have some other problem.
You do need to have a device configured to receive the CAN packet and return an ACK to not have an error from the transmitter - some CAN bus monitors do not do so as they are expected to be non-intrusive. In that case you will get an error from the transmitter if there is no other node.
You may need to put another normal CAN node on the network to get the correct response.