Hi!

I'd rather we added an option to have a v4/v6 table for source/destination for gif. Sort of like the table option for ipfw does.

So, I'm okay with this as it serves a real purpose, but I'd be much happier with a table driven solution.

Just curious, is it difficult to handle this situation by using multiple gif(4) interfaces?

Even if so, I am feeling we still need some measure to limit an address range because it makes injecting malicious packets easier. If I understand this load balancer case correctly, packet's source addresses which need to be accepted are in a small address range which can be calculated by using the address of gif(4)'s tunnel endpoint and an address mask. Thus it may be reasonable to implement prefix length option to allow a range of addresses instead of completely disabling the source address comparison.

Both table and "multiple gif interfaces" approaches require us to know in advance the exact list of sources. In our situation (connections come from IPVS balancer(s) with ipv6-in-ipv6 encapsulation, IPVS balancers are managed by other people) it is hard to keep this list up-to-date.

It will be point of failure when new IPVS balancer is added and everyone forget to add the corresponding gif interface.

As far as I understand, Linux' tunnel6 kernel modules acts like this: it ignores src, removes outer IP6 header and injects packet back to network stack for further processing.

Ok. I'm ok with this feature then. I recall the WCCP GRE IPv4 decapsulation setup is much the same.

Have you tested this on both v4 and v6 interfaces?

Speaking of me, I tested only IPv6 case.

We use this patch for two months, and if there are no objection against it, I'll commit it.