On 金,  8月 22, 2008 at 07:29:50午前 +1000, Simon Horman wrote:

On Thu, Aug 21, 2008 at 11:59:44AM +0200, Julius Volz wrote:

quoted

On Thu, Aug 21, 2008 at 3:17 AM, Simon Horman [off-list ref] wrote:

quoted

On Wed, Aug 20, 2008 at 06:15:07PM +0200, Julius Volz wrote:

quoted

What is not supported with IPv6:
- handling fragmentation or other extension headers
- FTP application helper (can be loaded, but only operates on v4)
- sync daemon (can be started, but only operates on v4)

Other than the packet format of the sync deamon, are there any
fundamental restrictions here? If we extended the sync daemon,
could it work? If so, perhaps we could rev the sync deamon protocol
and fix a few other kinks, like the handling of timeouts and the
general lack of extendability, at the same time.

There shouldn't be any fundamental restrictions, it's just a piece of
the puzzle that I could easily leave out of the picture for now.

I haven't studied the sync daemon closely yet, but one thing I was
briefly wondering about was whether we should just blow up the
addresses in struct ip_vs_sync_conn to be of type union nf_inet_addr
(probably not acceptable, wasting too much bandwidth for v4 entries)
or how to send differently sized entries based on the IP version in a
clean way. But it sounds like you'd want to redesign a lot of that
anyways? I'm glad to help with anything, I just don't know this code
as well as you or Sven, but I'll study it more. Maybe you can share
some ideas on the extensibility you want to see?

What I was thinking is that any change 

Sorry, I forgot to finish this sentance :-(

What I was thinking was that any change would introduce a
protocol incompatibility. However I think that there is
some room for small changes to be added using currently unsued
bits in ip_vs_sync_conn.flags. This could also be used to
allow syncryonising of timeouts (which is unrelated to IPv6).

So while my general feeling that the synchronisation protocol
is not as extendable as it should be stands. We can probably
work with the current protocol for now.