New version (or followup) of RIPE-501 document...
Dear RIPE IPv6 community. As promised, please find in attach new version (or followup) from RIPE-501 document. This document will get new version (if agreed in community) and will obsolete RIPE-501 as such. There is a promise, that RIPE-501 gets a link of new document, if/when that happens. What are major changes? We added CPE and mobile node requirements, we added some wording and explanations and we also took 2 options away, leaving with only 1 option. Main idea of new document is elaborated old option 3, in short: "Request IPv6 Ready Logo certificate, if equipment was not put under this testing require list of RFCs that needs to be supported. Note that IPv6 Ready Logo tests only basic requirements and if you have any special needs, request Logo and additional RFCs..." All is explained in a document. You'll see all possible colors in the docs. Black is what is left from original RIPE-501, different colors means different authors changes :) With this we hope to help you look at changes and spot them easily. There is .doc and .pdf versions attached. Authors would like to thnx all reviewers of this new document, we sent it firstly to all who contributed to previous version. You all know who you are :) Please, all comments and suggestions welcome and I expect vivid discussion here on the list. Goal is to try to reach a consensus for November RIPE meeting, if possible. Cheers from hard working ex-501 team - Merike, Sander and Jan
Hi Jan, I've attached an updated version with my comments regarding Logo test support (*). There were a couple more RFCs supported in the testing. Best Regards, Erica On Jun 6, 2011, at 10:23 AM, Jan Zorz @ go6.si wrote:
Dear RIPE IPv6 community.
As promised, please find in attach new version (or followup) from RIPE-501 document.
This document will get new version (if agreed in community) and will obsolete RIPE-501 as such. There is a promise, that RIPE-501 gets a link of new document, if/when that happens.
What are major changes? We added CPE and mobile node requirements, we added some wording and explanations and we also took 2 options away, leaving with only 1 option.
Main idea of new document is elaborated old option 3, in short:
"Request IPv6 Ready Logo certificate, if equipment was not put under this testing require list of RFCs that needs to be supported. Note that IPv6 Ready Logo tests only basic requirements and if you have any special needs, request Logo and additional RFCs..."
All is explained in a document.
You'll see all possible colors in the docs. Black is what is left from original RIPE-501, different colors means different authors changes :) With this we hope to help you look at changes and spot them easily.
There is .doc and .pdf versions attached.
Authors would like to thnx all reviewers of this new document, we sent it firstly to all who contributed to previous version. You all know who you are :)
Please, all comments and suggestions welcome and I expect vivid discussion here on the list. Goal is to try to reach a consensus for November RIPE meeting, if possible.
Cheers from hard working ex-501 team - Merike, Sander and Jan <Requirements-for-IPv6-in-ICT-equipment-v.1.pdf><Requirements-for-IPv6-in-ICT-equipment-v.1.doc>
Erica Johnson, Director UNH InterOperability Laboratory (UNH-IOL) o: 1.603.862.0117 m: 1.603.421.4802 http://www.iol.unh.edu
Hi Working group, First of all, apologies to you Erica. By no means trying to pick on you. May I request people to post clear text comments to the list and leave the actual document editing to the original authors. Not everybody runs Word or other proprietary software and we want to keep this working group open to everybody. It also makes it easier to track changes and versions. Thanks, MarcoH IPv6 Working Group co-chair
On 6/6/11 5:04 PM, Erica Johnson wrote:
Hi Jan,
I've attached an updated version with my comments regarding Logo test support (*). There were a couple more RFCs supported in the testing. Erica, thnx for corrections, inserted in main document :)
Cheers, Jan
Dear Colleagues, We had a quick chat with the original authors on how the process should look. As this document in itself does not try to set or modify policy, we are not going to formally apply the Policy Development Process on it. However we do want to structure the work a bit so it has been proposed to use similar timelines. The authors have agreed on a four week "review" period of the current draft. If you have any comments or additions regarding this document please make these known to the mailing list or the authors before Tuesday July 5th 2011. After this date the suggestions will be processed and a new version will be published to reflect the discussion that hopefully took place. We would also kindly ask you to voice your support of this document when you agree to the proposed text. This will help us to move forward knowing there is community support to publish a new version of the ripe-501 document. Thanks, The IPv6 WG chairs, Marco, Shane and David
On 6/7/11 9:19 AM, Marco Hogewoning wrote:
We would also kindly ask you to voice your support of this document when you agree to the proposed text. This will help us to move forward knowing there is community support to publish a new version of the ripe-501 document. Dear v6 WG :)
Wv6Day is over and we are switching back to regular schedule. We received some off-list comments for RIPE-501 followup (or next version) document, but we would like to encourage more people to read the draft, posted here on 6.6.2011 and comment - or express support if they agree with the text. There is at least one voting point in the draft, which CPE spec variant should we leave in the final doc and we need your input on that. We like both of them, which one you prefer? Thnx and cheers from the authors, Merike, Sander and Jan
On 06/16/2011 11:31 AM, Jan Zorz @ go6.si wrote:
On 6/7/11 9:19 AM, Marco Hogewoning wrote:
Greetings to all,
We would also kindly ask you to voice your support of this document when you agree to the proposed text. This will help us to move forward knowing there is community support to publish a new version of the ripe-501 document. Dear v6 WG :)
Wv6Day is over and we are switching back to regular schedule.
We received some off-list comments for RIPE-501 followup (or next version) document, but we would like to encourage more people to read the draft, posted here on 6.6.2011 and comment - or express support if they agree with the text.
There is at least one voting point in the draft, which CPE spec variant should we leave in the final doc and we need your input on that. We like both of them, which one you prefer?
My personal preference is variant 2. Less text is good I think. A more general question regarding this work is, would you consider "load balancers" as network elements that should be included? I know that load balancing can also be achieved at the application layer, but in the v4 world there are dedicated appliances that provide the functionality and are considered network infrastructure elements. Finally, since I don't have the technical expertise to thoroughly verify the lists of RFCs mentioned, a comment for the writing structure of the document. I can imagine that this is still work in progress but I find the document difficult to read with this structure. Certainly having a table of contents with sections and subsections will help.
Thnx and cheers from the authors, Merike, Sander and Jan
Regards and thanks for the very good work. Kostas Zorbadelos
On 6/17/11 2:08 PM, Kostas Zorbadelos wrote:
My personal preference is variant 2. Less text is good I think.
Agree to some extent... What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list. still not sure...
A more general question regarding this work is, would you consider "load balancers" as network elements that should be included? I know that load balancing can also be achieved at the application layer, but in the v4 world there are dedicated appliances that provide the functionality and are considered network infrastructure elements.
Interesting, we got this conversation with F5 guy in London this week. Maybe we could :)
Finally, since I don't have the technical expertise to thoroughly verify the lists of RFCs mentioned, a comment for the writing structure of the document. I can imagine that this is still work in progress but I find the document difficult to read with this structure. Certainly having a table of contents with sections and subsections will help.
Table of contents is coming in last version, but if community thinks in general that table of contents would help then we could make an effort and do it now... /jan
Jan,
My personal preference is variant 2. Less text is good I think.
Agree to some extent...
What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list.
still not sure...
RFC6104 _is_ just that; a device profile to be used for procurement. replicating this work in RIPE-501 seems redundant and more cause for confusion than help. we do after all have 3 of the IPv6 CPE profiles now. eRouter from CableLabs, TR-124i2 from BroadbandForum and RFC6104 from the IETF. cheers, Ole
On 6/18/11 8:11 PM, Ole Troan wrote:
Jan,
My personal preference is variant 2. Less text is good I think.
Agree to some extent...
What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list.
still not sure...
RFC6104 _is_ just that; a device profile to be used for procurement. replicating this work in RIPE-501 seems redundant and more cause for confusion than help. we do after all have 3 of the IPv6 CPE profiles now. eRouter from CableLabs, TR-124i2 from BroadbandForum and RFC6104 from the IETF.
ok, so I understand this as vote for variant 2. :) anyone else care for voting? Ole, don't get me wrong, We are just doing the sanity check with community. Less text is more. /jan
On Jun 19, 2011, at 11:39 AM, Jan Zorz @ go6.si wrote:
On 6/18/11 8:11 PM, Ole Troan wrote:
Jan,
My personal preference is variant 2. Less text is good I think.
Agree to some extent...
What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list.
still not sure...
RFC6104 _is_ just that; a device profile to be used for procurement. replicating this work in RIPE-501 seems redundant and more cause for confusion than help. we do after all have 3 of the IPv6 CPE profiles now. eRouter from CableLabs, TR-124i2 from BroadbandForum and RFC6104 from the IETF.
ok, so I understand this as vote for variant 2. :)
anyone else care for voting?
Ole, don't get me wrong, We are just doing the sanity check with community. Less text is more.
On a personal note: I agree with Ole, it is redundant to split it all up and in the long run it could also lead to discrepancies between the two. Stick with referring to 6104 and be done with it. Questions or comments on the exact profile can be directed at the IETF, making it the same with the references to 3Gpp. Marco
On 6/19/11 11:34 AM, Marco Hogewoning wrote:
On a personal note: I agree with Ole, it is redundant to split it all up and in the long run it could also lead to discrepancies between the two. Stick with referring to 6104 and be done with it. Questions or comments on the exact profile can be directed at the IETF, making it the same with the references to 3Gpp. Taken into account.
3:0 for short text. /jan
4:0 for the short text.
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz Sent: Sunday, June 19, 2011 2:06 PM To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] New version (or followup) of RIPE-501 document...
On a personal note: I agree with Ole, it is redundant to split it all up and in the long run it could also lead to discrepancies between the two. Stick with referring to 6104 and be done with it. Questions or comments on
On 6/19/11 11:34 AM, Marco Hogewoning wrote: the exact profile can be directed at the IETF, making it the same with the references to 3Gpp. Taken into account.
3:0 for short text.
/jan
5:0 please! Us On 06/20/2011 11:49 AM, Ivan Pepelnjak wrote:
4:0 for the short text.
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz Sent: Sunday, June 19, 2011 2:06 PM To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] New version (or followup) of RIPE-501 document...
On a personal note: I agree with Ole, it is redundant to split it all up and in the long run it could also lead to discrepancies between the two. Stick with referring to 6104 and be done with it. Questions or comments on
On 6/19/11 11:34 AM, Marco Hogewoning wrote: the exact profile can be directed at the IETF, making it the same with the references to 3Gpp. Taken into account.
3:0 for short text.
/jan
On 18 Jun 2011, at 19:11, Ole Troan wrote:
Jan,
My personal preference is variant 2. Less text is good I think.
Agree to some extent...
What does one RFC means to procurement people and how they check if CPE fits the requirements? In this case procurement guy needs to interpret all requirements from one RFC instead of the given list.
still not sure...
RFC6104 _is_ just that; a device profile to be used for procurement.
Actually, RFC6104 is something I know well, and it's not that. I think you mean RFC 6204 ;) I agree with Ole that replication is unnecessary. But if the RIPE community has differences to that list, it should state them. I don't think that 'weakens' 501-bis, rather it shows the operator community has genuine needs that differ from this and it would be prudent of vendors to take note of those needs. Note also that a very good reason for differences is that an 'advanced' CPE draft is in progress (draft-wbeebee-v6ops-ipv6-cpe-router-bis-04) which will have additional requirements, so perhaps 501-bis needs to decide if its idea of a CPE is that of 6204, or whether some things in the advanced draft need to be captured in 501-bis (which it seems they do). 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. Some comments; I've not read the new text in detail (yet). Switches: - add RA-Guard (RFC 6105 I think) Routers: - what about multicast routing? Searching on multicast in the text only seems to produce MLDv2 (which imo is a mandatory everywhere). - Embedded-RP is a must for multicast routing Firewalls: - surprised SeND is optional - if we're adding mobile nodes, we need the vendor and admin firewall drafts? But draft-ietf-mext-firewall-vendor-04 and draft-ietf-mext-firewall-admin-04 would definitely be optional unless you must have MIPv6 running Tim
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.
... and some of us had to deploy NAT-PT on an obsolete router just to make 6-to-4 transition before hitting the 6-unaware LBs. Nasty. Agreed - LBs should be made part of the document.
Switches: - add RA-Guard (RFC 6105 I think)
Agreed. Absolutely mandatory for any somewhat-secure deployment.
Firewalls: - surprised SeND is optional
How many people are deploying SeND? Even in DMZ? Ivan
On 20 Jun 2011, at 10:53, Ivan Pepelnjak 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.
... and some of us had to deploy NAT-PT on an obsolete router just to make 6-to-4 transition before hitting the 6-unaware LBs. Nasty.
Well, if that was your option, maybe better to not take part. Though I hear a lot of sites did this.
Firewalls: - surprised SeND is optional
How many people are deploying SeND? Even in DMZ?
Fair point. There are other ways to deploy a DMZ to help protect against the types of attack SeND can mitigate. Tim
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. Regards, Kostas
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
On 20 Jun 2011, at 13:30, Ivan Pepelnjak wrote:
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. Tim
Lack of IPv6 support in some LB products has nothing to do with orthodox beliefs in purity of NAT-less IPv6 world and all to do with the vendors' decisions to cut hardware costs by supporting only 32-bit addresses in their hardware implementation (if you have a software-only LB that still doesn't support IPv6 today, please let me know ;). And of course some of us were stupid enough (or trusting the vendor, which is the same thing) not to check whether the appliance we bought a few years ago will ever support IPv6. Ivan
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.
Tim
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 :) /jan
The minimum you need for load balancers is IPv6 host support, you might add OPTIONAL support for routing protocols. Obviously they need to support 6-to-4 and 6-to-6 load balancing ... are there any RFCs covering those? Ivan
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: Monday, June 20, 2011 6:33 PM To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] New version (or followup) of RIPE-501 document...
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 :)
/jan
Quoting Ivan Pepelnjak <ip@ioshints.info>:
The minimum you need for load balancers is IPv6 host support, you might add OPTIONAL support for routing protocols.
Obviously they need to support 6-to-4 and 6-to-6 load balancing ... are there any RFCs covering those?
This is indeed the question. Is there any work (in IETF probably) that describes what a load balancer is and what it should support in an IPv6 environment? If not I think we need to improvise. I also think that load balancing is crucial to the deployment not only for IPv6 content but any IPv6 service that needs to scale. Kostas
Ivan
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
Hi, A loadbalancer is a loadbalancer is a loadbalancer..... It should perform the same function in v6 as in in v4. So is there a definition on loadbalancers in general? Do we need to define what layer it´s working on? Regards Jonas
-----Ursprungligt meddelande----- Från: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] För Sander Steffann Skickat: den 20 juni 2011 21:38 Till: Jan Zorz@ Kopia: ipv6-wg@ripe.net Ämne: 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
Hi,
A loadbalancer is a loadbalancer is a loadbalancer..... It should perform the same function in v6 as in in v4. So is there a definition on loadbalancers in general? Do we need to define what layer it´s working on?
I don't know... We might. If we are going to provide guidelines for tender initiators for buying load balancers, what useful guidelines can we provide? We provide a list of mandatory and optional RFCs for the other equipment, so which RFCs does a load balancer need to support? - Sander
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
Hi,
[...]
Oh, and I never claimed I know anything about load balancers, so I might be totally wrong ;)
It seems to be useful input, so thank you anyway ;-) Sander
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
There must be better ways to address the problem in an IPv6 environment with L4 termination or L7 application layer proxies coming to mind.
I guess not many ops-focused people have the luxury to care. Regardless of how you do it, you lose end-to-end connectivity and some visibility (the latter is BTW mandated by some standards like PCI).
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.
In a perfect world with perfectly architected and implemented TCP stacks and no security issues mandating browser DNS pinning, you're absolutely correct. In the imperfect world we have to live in, you usually stop fighting the windmills and use a single IP address if you have to get enough nines. Ivan
On 6/21/11 9:34 AM, Ivan Pepelnjak wrote:
There must be better ways to address the problem in an IPv6 environment with L4 termination or L7 application layer proxies coming to mind.
I guess not many ops-focused people have the luxury to care. Regardless of how you do it, you lose end-to-end connectivity and some visibility (the latter is BTW mandated by some standards like PCI).
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.
In a perfect world with perfectly architected and implemented TCP stacks and no security issues mandating browser DNS pinning, you're absolutely correct.
In the imperfect world we have to live in, you usually stop fighting the windmills and use a single IP address if you have to get enough nines.
Ivan
Pragatism as paradigm. I like that. BTW, do we have any LB vendor on the list with some useful suggestion? Cheers, /jan
On 6/21/11 8:08 AM, Ivan Pepelnjak wrote:
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.
Hi, OK, we need to get out to the mailinglist next revision od RIPE-501 followup document somewhere in next week. LB spec is the thing, that is not done yet, as there are N+1 opinions (N being the number of people I talk to about this matter :) ) Are there any RFCs describing the above requirements? Question is - how "deep" we need to go with the mandatory part of the spec? As far as network is concerned, LB is a host that receives connections and magically re-distributes them to end hosts. It's not a router and it breaks end2end. How to specify that? :)
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.
So this looks like "host" spec could be the starting point of new spec?
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.
We could put all *NAT* and L4+ stuff in optional requirements. Probably the goal is to describe IPv6 load balancer, that would work in IPv6 only environment and IPv6 only clients and servers. Am I wrong? All this "put the balancer to serve v6 clients from v4 servers" rubbish makes this task nearly impossible.
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_.
So, "host" with added some routing options.
Oh, and I never claimed I know anything about load balancers, so I might be totally wrong ;) Ivan
We know you ;) Cheers, /jan
Are there any RFCs describing the above requirements?
Couldn't find any. I guess you're not interested in RFC 1794 ;)) [...]
So this looks like "host" spec could be the starting point of new spec?
I would say LB MUST conform to "host" spec. Those load balancers that provide routing functionality MUST conform to "router" specs.
We could put all *NAT* and L4+ stuff in optional requirements. Probably the goal is to describe IPv6 load balancer, that would work in IPv6 only environment and IPv6 only clients and servers. Am I wrong?
Load balancing between IPv6 clients and IPv6 and IPv4 servers (6-to-6 and 6-to-4) is a short-term MUST. 4-to-6 is a longer-term SHOULD. Mixed v4/v6 servers behind the same outside virtual IPv6 address is a SHOULD. Support for X-forwarded-for (or equivalent) header in HTTP is a MUST (otherwise the servers lose any visibility into who the client is). I don't think you can specify anything more than this. Ivan
On 7/16/11 8:40 PM, Ivan Pepelnjak wrote:
I would say LB MUST conform to "host" spec. Those load balancers that provide routing functionality MUST conform to "router" specs.
Well, we can take the spec of host and tweak it - as by definition that we use "A host is a network participant that sends and receives packets but does not forward them on behalf of others." LB can't be just host :) Now we just need to see which routing protocols are commonly used in load balancers and what requirements to get from Router spec section.
We could put all *NAT* and L4+ stuff in optional requirements. Probably the goal is to describe IPv6 load balancer, that would work in IPv6 only environment and IPv6 only clients and servers. Am I wrong?
Load balancing between IPv6 clients and IPv6 and IPv4 servers (6-to-6 and 6-to-4) is a short-term MUST. 4-to-6 is a longer-term SHOULD.
Maybe we can write this requirements as wording, not as RFC pointer...
Mixed v4/v6 servers behind the same outside virtual IPv6 address is a SHOULD.
Support for X-forwarded-for (or equivalent) header in HTTP is a MUST (otherwise the servers lose any visibility into who the client is).
this is also non-RFC requirement... Let's see what I can do. /jan
BTW, just to let you know, there is a Cisco position paper on RIPE-501 :) http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/brief_c80-... We should probably address their comments, specially the one that talks about RFC sets: "In option 1, RIPE-501 cherry-picks requirements from USGv6 and then adds its own without enough justification. We think that weakens the credibility of the document." We got solid consensus on RFC sets and changes were not taken "out-of-the-blue". I think we need to stress out this fact in the document. Any suggestions? /jan
participants (13)
-
Erica Johnson -
Ivan Pepelnjak -
Ivan Pepelnjak -
Jan Zorz -
Jan Zorz ＠ go6.si -
jonas.lindkvist＠trafikverket.se -
Kostas Zorbadelos -
kzorba＠otenet.gr
-
Marco Hogewoning -
Ole Troan -
Sander Steffann -
Tim Chown -
Us