netdev - Re: [PATCH RFC 00/24] IPVS: Add first IPv6 support to IPVS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.1.10.0808221316530.10895@titan.stealer.net>
Date:	Fri, 22 Aug 2008 13:23:04 +0200 (CEST)
From:	Sven Wegener <sven.wegener@...aler.net>
To:	Julius Volz <juliusv@...gle.com>
cc:	Graeme Fowler <graeme@...emef.net>,
	Simon Horman <horms@...ge.net.au>, netdev@...r.kernel.org,
	lvs-devel@...r.kernel.org, kaber@...sh.net, vbusam@...gle.com
Subject: Re: [PATCH RFC 00/24] IPVS: Add first IPv6 support to IPVS

On Fri, 22 Aug 2008, Julius Volz wrote:

> On Fri, Aug 22, 2008 at 12:05 PM, Graeme Fowler <graeme@...emef.net> wrote:
> > On Fri, 2008-08-22 at 11:56 +0200, Julius Volz wrote:
> >> There's also a '__u8 reserved' field at the beginning of that struct
> >> which could be used. But in general, is it reasonable to expect both
> >> nodes to use the same kernel version, which gets rid of the
> >> extensibility problems? It's not really an ABI that can't be broken,
> >> right?
> >
> > I think from an operational (ie. end user) perspective, ABI breakage is
> > something to try to avoid but _not_ at all costs.
> >
> > If it's possible to extend the sync daemon protocol by reusing the
> > existing code and ABI, all well and good; however if a fundamental
> > change is made which breaks the old sync daemon ABI then as long as it's
> > documented and we make sure that users know to have the same (or higher)
> > kernel versions on their directors then everyone wins.
> 
> Yeah, and it's not an ABI, it's a very specialized protocol between
> two kernels, so the rules are less clear. However, I totally agree
> with you that it's not convenient from the users' point of view.
> 
> >> Yes, without jumping through hoops, we have to probably break the
> >> current protocol anyways for new features? Even if we designated
> >> unused fields for new information, an old kernel will not look at them
> >> / fill them out, which limits the possibilities...
> >
> > I guess that as and when this change is made and gets into mainline
> > releases, Joe and I will have to have a mantra of "ensure your directors
> > are using the same kernel version" in response to queries on
> > lvs-users :)
> 
> He :) Imagine an old kernel on the backup receiving new messages and
> not understanding them. How could we at least handle that situation
> gracefully (without totally confusing the older kernel)? We'd need to
> do it in a way that old features are still communicated in the same
> way. E.g., v4-only connection syncs still use the same message format,
> but once you use v6 entries, an unused flag or the 'reserved' field in
> ip_vs_sync_conn is used. A v6 message would still confuse an older
> kernel then, but a user would already notice that ipvsadm can't
> configure the v6 services on the older kernel, so that's not too bad.

If that's a problem, we can easily change the communication port and even 
completely redesign the protocol this way, without having old kernels 
getting confused about the data they get. We might lose the ability to 
sync between different versions, but in the end this is just the 
connection synchronziation and both systems should be running the same 
version. We could also keep the old communication port for some time, if 
that's really needed.

Sven
--
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