[RFC][PATCH][IPSEC][0/3]inter address family ipsec tunnel

[RFC][PATCH][IPSEC][0/3]inter address family ipsec tunnel

[Kazunori MIYAZAWA]

Hello,

I fixed the compile issue when we configure IPv6 as a module.

[1/3] exporting xfrm_state_afinfo
[2/3] supporting IPv6 over IPv4 IPsec
[3/3] supporting IPv4 over IPv6 IPsec

These patches can be applied to linux-2.6.20-rc2.

Thank you,

--
Kazunori Miyazawa

Re: [RFC][PATCH][IPSEC][0/3]inter address family ipsec tunnel

[David Miller]

From: Kazunori MIYAZAWA <kazunori@miyazawa.org>
Date: Fri, 29 Dec 2006 14:47:02 +0900

> I fixed the compile issue when we configure IPv6 as a module.
> 
> [1/3] exporting xfrm_state_afinfo
> [2/3] supporting IPv6 over IPv4 IPsec
> [3/3] supporting IPv4 over IPv6 IPsec
> 
> These patches can be applied to linux-2.6.20-rc2.

Thank you.  This is not a bad solution to the symbol
export problem, for now.

I noticed that there is no need for the module symbol
export of xfrm6_output() you added, because xfrm6_output.o
and xfrm6_state.o always get linked together.

So I will remove that:

+EXPORT_SYMBOL(xfrm6_output);

part of the first patch.

We see so many issues with ipv6 symbols dependencies in various
subsystems (netfilter, xfrm, etc.).  It is a sign that we need
some kind of long range plan to deal with this problem.  Since
the ipv6 module can't be unloaded anyways, and it's been broken
like that forever, it might make sense to make ipv6 only available
non-modular.  I know people would dislike this, but the current
situation isn't good either.

Thanks again.

depending on IPv6 symbols (was: [RFC][PATCH][IPSEC][0/3]inter address family ipsec tunnel)

[Roland Dreier]

    David> We see so many issues with ipv6 symbols dependencies in
    David> various subsystems (netfilter, xfrm, etc.).  It is a sign
    David> that we need some kind of long range plan to deal with this
    David> problem.  Since the ipv6 module can't be unloaded anyways,
    David> and it's been broken like that forever, it might make sense
    David> to make ipv6 only available non-modular.  I know people
    David> would dislike this, but the current situation isn't good
    David> either.

Yes, coincidentally I just ran into this problem.  In the context of
reviewing a patch (IPoIB connected mode, which has to deal with
getting too-big packets for a given path) that basically wants to do

#ifdef CONFIG_IPV6
	if (...)
		icmpv6_send(...TOOBIG...)
#endif

I noticed that this exact problem already appears in
net/ipv4/ip_gre.c, which has exactly the same type of code:

#ifdef CONFIG_IPV6
	else if (skb->protocol == htons(ETH_P_IPV6)) {
		struct rt6_info *rt6 = (struct rt6_info*)skb->dst;

		if (rt6 && mtu < dst_mtu(skb->dst) && mtu >= IPV6_MIN_MTU) {
			if ((tunnel->parms.iph.daddr && !MULTICAST(tunnel->parms.iph.daddr)) ||
			    rt6->rt6i_dst.plen == 128) {
				rt6->rt6i_flags |= RTF_MODIFIED;
				skb->dst->metrics[RTAX_MTU-1] = mtu;
			}
		}

		if (mtu >= IPV6_MIN_MTU && mtu < skb->len - tunnel->hlen + gre_hlen) {
			icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, dev);
			ip_rt_put(rt);
			goto tx_error;
		}
	}
#endif

now obviously this means that if ipv6 is built modular, then the
correct handling for too-big packets will never be used.  But on the
other hand, if we convert the test to

#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)

then building with CONFIG_NET_IPGRE=y and CONFIG_IPV6=m will break,
because icmpv6_send() is no longer built in.  And obviously making
NET_IPGRE depend on IPV6 doesn't make sense.

So I hope we can come up with a short-range plan to deal with the
possibility of built-in code calling icmpv6_send() at least...  As you
said, should we just convert IPV6 to a bool instead of a tristate?

Thanks,
  Roland

Re: depending on IPv6 symbols

[David Miller]

From: Roland Dreier <rdreier@cisco.com>
Date: Tue, 06 Feb 2007 14:43:15 -0800

> So I hope we can come up with a short-range plan to deal with the
> possibility of built-in code calling icmpv6_send() at least...  As you
> said, should we just convert IPV6 to a bool instead of a tristate?

Netfilter handles this by using the Kconfig dependency construct:

config FOO
	depends on (IPV6 || IPV6=n)

which essentially means:

if IPV6 is disabled:

	Allow FOO to build modular or static, but will get no ipv6
	support.

if IPV6 is "y"

	Allow FOO to be a static or modular build

if IPV6 is "m"

	Allow FOO to be a modular build only

This is the only way to make it all work out currently.

Re: depending on IPv6 symbols

[Roland Dreier]

 > config FOO
 > 	depends on (IPV6 || IPV6=n)

OK, I'll add the same hack for INFINIBAND_IPOIB too.  I doubt there's
anyone that really cares about IPoIB built-in with modular IPv6.

Would you like a patch to do the same thing for INET_IPGRE (and fix
the #ifdefs in ip_gre.c)?

 - R.

Re: depending on IPv6 symbols

[David Miller]

From: Roland Dreier <rdreier@cisco.com>
Date: Tue, 06 Feb 2007 14:53:58 -0800

> Would you like a patch to do the same thing for INET_IPGRE (and fix
> the #ifdefs in ip_gre.c)?

Sure, although I'm surprised nobody noticed that build failure
before :-)

Re: depending on IPv6 symbols

[Roland Dreier]

    David> Sure, although I'm surprised nobody noticed that build
    David> failure before :-)

OK, coming up.  (It's not a build failure though, it's wrong code: if
CONFIG_IPV6=m then the code inside "#ifdef CONFIG_IPV6" in ip_gre.c
just doesn't get built, even though it should)

 - R.