Re: IPv6 transition work was RE: NANOG 40 agenda posted
On Sun, 3 Jun 2007, matthew zeier wrote: John Curran wrote: Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market... I suppose, but certain places like Mozilla, would be dead in the water without load balancers. Citrix got their act together and shipped 8.0 with v6 vips on the front talking to v4 servers on the backend. While I understand that some place may want to put policies that every v4 part must be exactly same as v6 I think more realistic view is better. You should have servers ready to answer v6 but look at your traffic - is it really necessary to add v6 to your load-balancer or would it be ok to just have record pointing to particular system (even if 7 others are available) because the amount of traffic makes more sense. Now when v6 traffic increase there would be more pressure for vendors to make load-balancers support v6 as well and you'd not have problems then. But if you're still thinking about v6 load-balancers, then I recommend taking a look at http://kb.linuxvirtualserver.org/wiki/IPVS -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: IPv6 transition work was RE: NANOG 40 agenda posted
william(at)elan.net wrote: . I suppose, but certain places like Mozilla, would be dead in the water without load balancers. Citrix got their act together and shipped 8.0 with v6 vips on the front talking to v4 servers on the backend. While I understand that some place may want to put policies that every v4 part must be exactly same as v6 I think more realistic view is better. You should have servers ready to answer v6 but look at your traffic - is it really necessary to add v6 to your load-balancer or would it be ok to just have record pointing to particular system (even if 7 others are available) because the amount of traffic makes more sense. Now when v6 traffic increase there would be more pressure for vendors to make load-balancers support v6 as well and you'd not have problems then. But if you're still thinking about v6 load-balancers, then I recommend taking a look at http://kb.linuxvirtualserver.org/wiki/IPVS For me, this seriously comes down to ease of deployment. I don't have to duplicate servers just for v6. Infact, all I have to do is add a v6 vip and I'm done. Oh, and it lets me roll v6 out in a production manner, HA and all. I do agree that the traffic level is nearly insignificant but the fact that my vendor supports it and I don't have to manage yet another system, makes my life easier. - mz
Re: IPv6 transition work was RE: NANOG 40 agenda posted
Understood. One more alternative to just keep the existing load-balancer infrastructure is to setup a NAT-PT box. Again, even if this may not scale for millions of users, it may be a good solution for the few users that can be accessing with IPv6 your contents. Of course, all this may not necessarily work for your infrastructure, I'm talking in raw mode, not knowing your network details, etc. Regards, Jordi De: Igor Gashinsky [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sun, 3 Jun 2007 19:16:06 -0400 (EDT) Para: JORDI PALET MARTINEZ [EMAIL PROTECTED] CC: nanog@merit.edu Asunto: Re: IPv6 transition work was RE: NANOG 40 agenda posted What I guess have not been clear on is the fact that loadbalancers for many people are an integral (and required) part of the *architecture* (and not just something u need to distribute load), and as such, are a component that must support v6 for the *service* to then be able to support it (much like basic logging now would need to be v6 capable, etc). There is simply no easy way of taking 1 machine and making it mail.ipv6.yahoo.com (as an example), not to mention that nobody is going to invest the time and resources into building a completely different architecture (a single server is a complete one-off) to support a test rollout of v6 (and then having to sync different code trees, etc), when that time and resources could be better invested in coming up with a real solution for the long-term. Again, we are working on it, it is much harder then it seems, my views are my own, I'm not in any way speaking for my employer, and in fact, I've said all I can. Thanks, -igor On Mon, 4 Jun 2007, JORDI PALET MARTINEZ wrote: :: :: Agree, and in fact, a quick though is that as you may expect *much less* :: IPv6 traffic today, not having load balancing may not be an issue, and you :: can always actively measure if the traffic is going high, etc. :: :: If the time arrives when the traffic is so high and your preferred vendor :: doesn't yet support the IPv6 load+IPv4 one, then you have no risk in the :: sense that you can just delete the records, but meanwhile you have a :: very realistic test environment and motivation to push your vendors, or :: considering the traffic, decide if moving to other vendors, etc. :: :: Regards, :: Jordi :: :: :: :: :: De: [EMAIL PROTECTED] :: Responder a: [EMAIL PROTECTED] :: Fecha: Sun, 3 Jun 2007 23:01:57 +0100 :: Para: [EMAIL PROTECTED] :: Conversación: IPv6 transition work was RE: NANOG 40 agenda posted :: Asunto: IPv6 transition work was RE: NANOG 40 agenda posted :: :: :: :: Without naming any vendors, quite a few features that work :: with hardware assist/fast path in v4, don't have the same :: hardware assist in v6 (or that sheer enabling of ipv6 doesn't :: impact v4 performance drasticly). :: Also, quite a few features simply are not supported in v6 :: (not to mention that some LB vendors don't support v6 at :: all). Just because it works, doesn't mean it works :: corrctly, or at the right scale. Again, not naming any vendors... :: :: This just emphasizes the importance of turning on IPv6 today either in :: some part of your production networks in order to identify the specifics :: of these issues and get them out in the open where they can be fixed. :: :: Actually, for me 100% feature parity (for stuff we use per :: vip) is a day-1 requirement. :: :: This doesn't sound like transition as we know it. If you can set up :: everything that you need to test in a lab environment and then certify :: IPv6 as ready for use, this could work. But I don't believe that the :: IPv6 transition can be handled this way. It involves many networks with :: services and end-users of all types which interact in interesting ways. :: We need everybody to get some IPv6 into live Internet production. The :: only way this can work is to take lots of baby steps. Turn on a bit of :: v6, test, repeat. :: :: My stance is that simply enabling v6 on a server in not :: interesting, v6 has to be enabled on the *service*, :: :: I disagree. If a company can offer their service using lots of IPv4 :: in-house with an IPv6 proxy gateway to the Internet, then this is still :: valuable and useful in order to support OTHER people's testing. Let's :: face it, IPv4 is not going away and even when the v4 addresses run out, :: anybody who has them can keep their services running as long as they :: don't need to grow the v4 infrastructure. This is not an issue of :: turning on some IPv6 to test it and then evaluate the results. The fact :: of IPv4 exhaustion is an imperative that means you and everyone else :: must transition to an IPv6 Internet. You turn on some v6, test, adjust, :: turn on some more, test, adjust and repeat until your infrastructure no :: longer has a dependency on new IPv4 addresses. Your end
Re: IPv6 transition work was RE: NANOG 40 agenda posted
This is one of the ways some load-balancer vendors do IPv6 today. They still talk IPv4 to the servers, so you don't need to modify anything, just add an managed by the load balancer. It is a kind of combination between NAT-PT and load-balancer. Regards, Jordi De: matthew zeier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sun, 03 Jun 2007 22:58:37 -0700 Para: John Curran [EMAIL PROTECTED] CC: Igor Gashinsky [EMAIL PROTECTED], nanog@merit.edu Asunto: Re: IPv6 transition work was RE: NANOG 40 agenda posted John Curran wrote: Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market... I suppose, but certain places like Mozilla, would be dead in the water without load balancers. Citrix got their act together and shipped 8.0 with v6 vips on the front talking to v4 servers on the backend. Rock on Citrix. ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: IPv6 transition work was RE: NANOG 40 agenda posted
Agree, and in fact, a quick though is that as you may expect *much less* IPv6 traffic today, not having load balancing may not be an issue, and you can always actively measure if the traffic is going high, etc. If the time arrives when the traffic is so high and your preferred vendor doesn't yet support the IPv6 load+IPv4 one, then you have no risk in the sense that you can just delete the records, but meanwhile you have a very realistic test environment and motivation to push your vendors, or considering the traffic, decide if moving to other vendors, etc. Regards, Jordi De: [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sun, 3 Jun 2007 23:01:57 +0100 Para: [EMAIL PROTECTED] Conversación: IPv6 transition work was RE: NANOG 40 agenda posted Asunto: IPv6 transition work was RE: NANOG 40 agenda posted Without naming any vendors, quite a few features that work with hardware assist/fast path in v4, don't have the same hardware assist in v6 (or that sheer enabling of ipv6 doesn't impact v4 performance drasticly). Also, quite a few features simply are not supported in v6 (not to mention that some LB vendors don't support v6 at all). Just because it works, doesn't mean it works corrctly, or at the right scale. Again, not naming any vendors... This just emphasizes the importance of turning on IPv6 today either in some part of your production networks in order to identify the specifics of these issues and get them out in the open where they can be fixed. Actually, for me 100% feature parity (for stuff we use per vip) is a day-1 requirement. This doesn't sound like transition as we know it. If you can set up everything that you need to test in a lab environment and then certify IPv6 as ready for use, this could work. But I don't believe that the IPv6 transition can be handled this way. It involves many networks with services and end-users of all types which interact in interesting ways. We need everybody to get some IPv6 into live Internet production. The only way this can work is to take lots of baby steps. Turn on a bit of v6, test, repeat. My stance is that simply enabling v6 on a server in not interesting, v6 has to be enabled on the *service*, I disagree. If a company can offer their service using lots of IPv4 in-house with an IPv6 proxy gateway to the Internet, then this is still valuable and useful in order to support OTHER people's testing. Let's face it, IPv4 is not going away and even when the v4 addresses run out, anybody who has them can keep their services running as long as they don't need to grow the v4 infrastructure. This is not an issue of turning on some IPv6 to test it and then evaluate the results. The fact of IPv4 exhaustion is an imperative that means you and everyone else must transition to an IPv6 Internet. You turn on some v6, test, adjust, turn on some more, test, adjust and repeat until your infrastructure no longer has a dependency on new IPv4 addresses. Your end game may still have lots of IPv4 in use which is OK as long as no new IPv4 addresses are needed. Like you said, different companies have different approaches, but if I'm going to invest my (and a lot of other engineers/developers/qa) time in enabling v6, it's not going to be putting a single server behind the mail.ipv6.yahoo.com rotation, it's going to be figuring out how to take everything that we use for mail.yahoo.com, and making it work in v6 (as that is the only way it would be concidered a valid test), so that at some point in the not-too-distant future it could become dual-stack... I don't disagree with the general thrust of your approach, in particular related to the investment that you have to make. But as part of your overall IPv6 transition program, it should not cause you a lot of pain to make the mail.yahoo.com service available to IPv6 users. By doing that you help everybody else move along in their transition process and you cut your costs because you will be able to leverage the lessons that other people learn. The network effect will help those who actually deploy stuff in production. --Michael Dillon ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: IPv6 transition work was RE: NANOG 40 agenda posted
What I guess have not been clear on is the fact that loadbalancers for many people are an integral (and required) part of the *architecture* (and not just something u need to distribute load), and as such, are a component that must support v6 for the *service* to then be able to support it (much like basic logging now would need to be v6 capable, etc). There is simply no easy way of taking 1 machine and making it mail.ipv6.yahoo.com (as an example), not to mention that nobody is going to invest the time and resources into building a completely different architecture (a single server is a complete one-off) to support a test rollout of v6 (and then having to sync different code trees, etc), when that time and resources could be better invested in coming up with a real solution for the long-term. Again, we are working on it, it is much harder then it seems, my views are my own, I'm not in any way speaking for my employer, and in fact, I've said all I can. Thanks, -igor On Mon, 4 Jun 2007, JORDI PALET MARTINEZ wrote: :: :: Agree, and in fact, a quick though is that as you may expect *much less* :: IPv6 traffic today, not having load balancing may not be an issue, and you :: can always actively measure if the traffic is going high, etc. :: :: If the time arrives when the traffic is so high and your preferred vendor :: doesn't yet support the IPv6 load+IPv4 one, then you have no risk in the :: sense that you can just delete the records, but meanwhile you have a :: very realistic test environment and motivation to push your vendors, or :: considering the traffic, decide if moving to other vendors, etc. :: :: Regards, :: Jordi :: :: :: :: :: De: [EMAIL PROTECTED] :: Responder a: [EMAIL PROTECTED] :: Fecha: Sun, 3 Jun 2007 23:01:57 +0100 :: Para: [EMAIL PROTECTED] :: Conversación: IPv6 transition work was RE: NANOG 40 agenda posted :: Asunto: IPv6 transition work was RE: NANOG 40 agenda posted :: :: :: :: Without naming any vendors, quite a few features that work :: with hardware assist/fast path in v4, don't have the same :: hardware assist in v6 (or that sheer enabling of ipv6 doesn't :: impact v4 performance drasticly). :: Also, quite a few features simply are not supported in v6 :: (not to mention that some LB vendors don't support v6 at :: all). Just because it works, doesn't mean it works :: corrctly, or at the right scale. Again, not naming any vendors... :: :: This just emphasizes the importance of turning on IPv6 today either in :: some part of your production networks in order to identify the specifics :: of these issues and get them out in the open where they can be fixed. :: :: Actually, for me 100% feature parity (for stuff we use per :: vip) is a day-1 requirement. :: :: This doesn't sound like transition as we know it. If you can set up :: everything that you need to test in a lab environment and then certify :: IPv6 as ready for use, this could work. But I don't believe that the :: IPv6 transition can be handled this way. It involves many networks with :: services and end-users of all types which interact in interesting ways. :: We need everybody to get some IPv6 into live Internet production. The :: only way this can work is to take lots of baby steps. Turn on a bit of :: v6, test, repeat. :: :: My stance is that simply enabling v6 on a server in not :: interesting, v6 has to be enabled on the *service*, :: :: I disagree. If a company can offer their service using lots of IPv4 :: in-house with an IPv6 proxy gateway to the Internet, then this is still :: valuable and useful in order to support OTHER people's testing. Let's :: face it, IPv4 is not going away and even when the v4 addresses run out, :: anybody who has them can keep their services running as long as they :: don't need to grow the v4 infrastructure. This is not an issue of :: turning on some IPv6 to test it and then evaluate the results. The fact :: of IPv4 exhaustion is an imperative that means you and everyone else :: must transition to an IPv6 Internet. You turn on some v6, test, adjust, :: turn on some more, test, adjust and repeat until your infrastructure no :: longer has a dependency on new IPv4 addresses. Your end game may still :: have lots of IPv4 in use which is OK as long as no new IPv4 addresses :: are needed. :: :: Like you said, different companies have different approaches, :: but if I'm going to invest my (and a lot of other :: engineers/developers/qa) time in enabling v6, it's not going :: to be putting a single server behind the mail.ipv6.yahoo.com :: rotation, it's going to be figuring out how to take :: everything that we use for mail.yahoo.com, and making it work :: in v6 (as that is the only way it would be concidered a valid :: test), so that at some point in the not-too-distant future it :: could become dual-stack... :: :: I don't disagree with the general thrust of your approach, in particular :: related
Re: IPv6 transition work was RE: NANOG 40 agenda posted
At 7:16 PM -0400 6/3/07, Igor Gashinsky wrote: Again, we are working on it, Good to know... it is much harder then it seems, my views are my own, I'm not in any way speaking for my employer, ... Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market... /John
Re: IPv6 transition work was RE: NANOG 40 agenda posted
John Curran wrote: Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market... I suppose, but certain places like Mozilla, would be dead in the water without load balancers. Citrix got their act together and shipped 8.0 with v6 vips on the front talking to v4 servers on the backend. Rock on Citrix.
