[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101005062732.GA27337@gondor.apana.org.au>
Date: Tue, 5 Oct 2010 14:27:32 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Arnaud Ebalard <arno@...isbad.org>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <eric.dumazet@...il.com>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
netdev@...r.kernel.org
Subject: Re: [PATCHv4 net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook
in xfrm_input()
On Mon, Oct 04, 2010 at 10:51:46PM +0200, Arnaud Ebalard wrote:
>
> Either I don't understand the sentence or this is not feasible: the
> thing is there is nothing in the packet to demultiplex like nh for
> RH2/HAO. Here, we only lookup for a remapping state when there is a
> mismatch in the source/destination addresses expected for the SA.
>
> That's the reason IRO remapping states only apply to IPsec traffic.
I see.
The thing that bugs me is that you've added an indirect call for
all IPsec traffic when only MIPv6 users would ever need this.
With your remapping, would it be possible to add dummy xfrm_state
objects with the remapped destination address that could then call
xfrm6_input_addr?
That way normal IPsec users would not be affected at all while
preserving your new functionality.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists