This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] New version (or followup) of RIPE-501 document...
- Previous message (by thread): [ipv6-wg] New version (or followup) of RIPE-501 document...
- Next message (by thread): [ipv6-wg] New version (or followup) of RIPE-501 document...
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ivan Pepelnjak
ip at ioshints.info
Mon Jun 20 14:30:34 CEST 2011
> On 06/20/2011 12:40 PM, Tim Chown wrote: > > I think load balancers should be included; I know some universities who > did not take part in W6D not because their web servers couldn't be made v6 > ready, but because their load balancers could not. > > Although the thread may deviate a bit, since we got into the topic of > load balancers, does anyone have any pointers or references to work > describing how load balancers can/should operate in an IPv6 environment? > > The reasons for asking are: > > - we need such references to include in RIPE-501 > - in the IPv4 world a lot of the load balancing logic has to do > with NAT. In IPv6, NAT should be a forbidden notion. Of course someone > could just terminate connections and open new ones in backend farms of > machines effectively acting as an application layer proxy. 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. Of course those vendors that can do high-speed TCP termination (sometimes even in hardware) will tell you why that's infinitely better ... and the purists will be happy because you've replaced abhorred NAT with oh-so-much-better TCP relay ;) Unfortunately, the net result is the same - loss of direct end-to-end client-to-server connectivity. Just my mildly sarcastic view of the NAT-in-LB topic Ivan
- Previous message (by thread): [ipv6-wg] New version (or followup) of RIPE-501 document...
- Next message (by thread): [ipv6-wg] New version (or followup) of RIPE-501 document...
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]