On 06/21/2011 09:08 AM, Ivan Pepelnjak wrote: I also do not claim to be any kind of expert, I am just interested in the load balancing subject ;-) First of all, I must say that I am on the purist side. I don't like NAT and I am a bit skeptic about employing NAT for load balancing even in the IPv4 world. Having said that, our current production setup relies heavily on load balancers doing NAT in their internal workings. There must be better ways to address the problem in an IPv6 environment with L4 termination or L7 application layer proxies coming to mind. For me however, for a load balanced service, the requirement is one name in the DNS and not a single IP (v4 or v6) address. I can understand that it is a very wide subject and I don't have an answer of how to address it in a document like RIPE 501. Regards, Kostas
From the "outside" perspective, a load-balanced service implemented with one or more redundant load balancers _MUST_ look like an IPv4 _OR_ an IPv6 address (where OR is not exclusive, but AND is not strictly necessary) distributing sessions to IPv4 or IPv6 inside nodes. It _SHOULD_ be able distribute sessions arriving to an outside address (IPv4 or IPv6) to a mixed cluster of IPv4 _AND_ IPv6 addresses.
How a LB device implements its magic (L4 passthrough with NAT, L4 termination, L7 proxy, whatever other tricks) is irrelevant (and seems there are no "obvious" RFCs documenting it). What is MANDATORY is that it supports connections from IPv6 clients to IPv4 and/or IPv6 servers and from IPv4 clients to IPv4 and/or IPv6 servers (see last sentence in the previous paragraph) to enable all possible migration scenarios.
However, I would recommend that for 6-to-4 functionality, we _RECOMMEND_ the load balancer adheres to the RFC6146 (stateful NAT64) - we should discourage (but not forbid) vendors from doing homebrew 6-to-4 translation when a standard exists specifying how to do it.
On the IPv6 protocol side, the very minimum requirement is adherence to IPv6 host behavior. Some LB designs work without significant support for routing - single inside and outside /64 with RA-generated default route on the outside - or they could support some routing protocols. Those should (in my opinion) be made _OPTIONAL_.
Oh, and I never claimed I know anything about load balancers, so I might be totally wrong ;) Ivan
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: Monday, June 20, 2011 9:38 PM To: Jan Zorz @ go6.si Cc: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] New version (or followup) of RIPE-501 document...
Hi,
Getting more and more off-topic, but regardless of what purists might think, load balancing is a crucial function (until TCP stack and/or socket API get fixed - read: not likely) and at least some of them do and will use some sort of NAT to do their job.
I think this is the key point. While providers are not putting up content on IPv6 for this reason, it is an issue.
Ok, so I see some consensus on the question, if load balancers are needed in RIPE-501 foloowup document or not. The answer is yes.
My question is, should we create new hw category for this or should we put it in any of existing category?
Merike, Sander, I'm inviting you back to drawing board to fix this request :)
Invitation accepted :-)
The difficult bit is defining 'load balancer'... There are so many different ways to implement this, at different layers. I have seen layer-7 proxy based load balancers, but also layer-3 direct-routing ones, with other options in between. Some look like a client to the back end servers, but others need cooperation from those servers. The sum of load balancers and back end servers have to look like an end-node to the outside world, but inside anything (well, almost) is possible.
So, can we compile a list of load balancing methods and can we specify what is needed for each method? Do we want to do this? Or can we say 'the server farm as a whole needs to behave like an end-node'?
But I fully agree: we need to say *something* about load balancers! Sander