On Fri, 2006-10-06 at 12:17 -0400, James Carlson wrote: > 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.
In that case, it's no longer generic IP in IP tunneling, but some more intelligent protocol. > 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. Yes, I agree that Solaris has a need for more useful tunneling protocols that don't have these constraints. We still need to support the existing ones, as they're interoperable with other implementations of IP-in-IP tunneling that are just as "dumb" as our own. :-) > > > 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. Yes, but then that places a constraint on the configuration of interfaces that don't exist today. That would be a regression. > 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. It certainly would do that. > > 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. I think this is a reasonable approach, and this is the same approach that was used to allow the "tdst" to bind even if the address isn't covered by a forwarding table entry. > > > 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. Ah, I see. I misunderstood your idea. In that model, one would administratively create a tunnel data-link, but the data-link would not actually be created until a daemon determines that the appropriate pre-requisites have been met. > > > 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? I understand. > 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 agree with that, however if we remove the dependencies that tunnel creation currently has, then that addresses the immediate need for any policy relative to the other network interfaces. > I'm not talking about DL_NOTE_LINK_UP. I'm talking about configuring > the tunnel. Yeah, I just misunderstood your original point. > > > 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. I'm in agreement with that at this point. Let's work out the details of the solution on clearview-discuss. I'll propose a solution there. > 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. Okay. -Seb
