Sebastien Roy writes: > > For what it's worth, and though we don't allow this today, it'd be > > entirely reasonable to allow an unspecified tsrc, in exactly the same > > way an application can bind an unspecified source address. The > > meaning is exactly the same: on outbound packets, we choose a source > > address based on the next hop lookup, and on inbound, we allow any > > local IP address to match. > > That would not be reasonable, as it wouldn't work at all. The other > side of the tunnel has a specific IP address configured as its > destination, and that must be exactly the IP address we use to originate > packets. This is what the other side uses to demultiplex packets we > send to it to a specific tunnel data-link.
Yep; understood. This means only that either (a) you need to have a way of making sure that address doesn't change unless the remote configuration changes or (b) that the remote end is sophisticated enough to understand that the peer has multiple possible source addresses. It doesn't actually mean that an address needs to be _bound_ locally. UDP has a similar problem, but it's alleviated (somewhat) by the use of port numbers, though address changes are still sometimes troublesome. We might be better off long term if we can figure out how to do GRE over UDP rather than (or in addition to) IP-IP, as there are a lot fewer ambiguous cases. > > And, of course, if you have multiple output interfaces, you can use > > "usesrc" to make sure that a consistent address is used. > > That's not what "usesrc" does. It allows for selection of the source > address to use another interfaces "set" of addresses to choose from, but > it does not restrict that selection to a single address. It does if the interface you point to with that option has just one address. The advantage is that you don't have to care what that address is, at least as far as local tunnel configuration goes, and you don't have to wait for any special condition to occur before binding. An almost equivalent (but maybe not as good) solution is to allow tsrc to bind even when it represents an address that isn't currently valid on the local system. Then, at least, you've got some decoupling between tunnel configuration and the rest of the IP interface configuration. > > This actually sounds to me like it's in the same class of problems as > > with static route management. A better answer for those is to have > > some sort of user-space daemon (such as Quagga's zebrad) that's able > > to implement policy rules to determine what things to bring up, and > > when to bring them up. > > I don't understand the logic here. We need to do two things when a > tunnel's source is brought into existence. > > 1. bind the tunnel with the ip module > 2. send up a DL_NOTE_LINK_UP to the upper instance of ip so that the IP > interface's IFF_RUNNING flag can reflect the state of the underlying > tunnel link. > > Both of those things can easily be done by the tunneling kernel module, > and both of those things can't be done by a daemon... Why not just have > the kernel module detect the right condition and do the right thing? I think we're talking about different things here. I'm talking about deciding when to bring the tunnel's source into existence, not what must be done afterwards. > Anyway, I think this discussion probably belongs as a design discussion > relating the the Clearview IP Tunneling Device Driver. The IP tunneling > SMF service will be introduced by Clearview. It's probably worth > continuing this discussion on clearview-discuss and reporting the > results here. Yep. > > So, no, I don't think it's related to packet filtering hooks or other > > kernel-resident mechanisms, unless that's just a means to a simpler > > end. Burying policy in the kernel sounds hazardous to me. > > What policy, and how is it hazardous? There's no user-land daemon that > detects when a wire is plugged in to the system so that an Ethernet > driver can send up a DL_NOTE_LINK_UP. How is this different? The policy issue is determining when and if to add a given tunnel endpoint to the kernel. Do you do it when a given local IP address becomes available? Or when a given route is torn down? Or when the user clicks on some "tunnel me now" button? Currently, the only policy is "wait until all other links have been plumbed and configured, just the ones that have static configuration or can be brought up 'quickly' and except for the ones that might be dynamically configured or end up taking 'too long' to address, and then take a swing at configuring the tunnel." I don't think that's a comprehensive policy. I'm not talking about DL_NOTE_LINK_UP. I'm talking about configuring the tunnel. If you really want the tunnel to be configured automatically when possible, and not just stall the system waiting for other interfaces to come up first, then that implies some sort of daemon that determines when conditions are 'right' to set that configuration. I obviously agree that DL_NOTE_LINK_UP (whatever it represents in this case) needs to be in the kernel. > > For statically-configured tunnels, allowing an unspecified tsrc seems > > much simpler and much more robust. (Though I agree that the current > > implementation makes that tricky.) > > I disagree with that. Using an unspecified tsrc means that the source > address is indeterminate, and the protocol depends on fixed IP addresses > being used. It's the binding issue that has me annoyed here. I don't like the fact that we have the configuration of one IP interface dependent on the configuration of some otherwise unrelated interface. It makes the operational aspects quite strange and brittle. That doesn't happen in most other cases. We don't have wireless links depending on wired links to come up. The only other one that comes to mind is with PPP's proxy ARP mechanism, but there are likely better (decoupled) ways to implement that one as well. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
