nanog mailing list archives
Re: NANOG 40 agenda posted
From: Igor Gashinsky <igor () gashinsky net>
Date: Sun, 3 Jun 2007 15:52:17 -0400 (EDT)
On Sun, 3 Jun 2007, Donald Stahl wrote: :: > Not speaking directly for my employer (in any official capacity :: > that is), but it's is *not* as easy as as just IPv6 enabling our network, :: > enabling ipv6 on the servers, and putting up ipv6.yahoo.com. Currently, :: > the biggest roadblock we have is loadbalancer support (or, more :: > specificly, lack of thereof) for IPv6 (hell, we still can't even get a :: :: I don't know what load balancer you use but all the testing I've done with my :: F5's has worked out. Granted I'm sure I've forgotten to test some stuff along :: they way but it simply hasn't been an issue during the initial testing. :: Considering they support IPv6 gateway and IPv6 proxy modules you can :: generally make things work in your environment. 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... :: That said- your v6 support does not have to match your v4 support to at least :: allow you to begin testing. You could set up a single server with v6 support, :: test, and not worry about it affecting production. Actually, for me 100% feature parity (for stuff we use per vip) is a day-1 requirement. I'm not saying that it's an all or nothing deal, but I have absolutely no intention of having 100% different set-up for the current v4 and the "test v6", and then have to troubleshoot v6 issues, not being sure if something was simply not carried over from v4 that it should have been. My stance is that simply enabling v6 on a server in "not interesting", v6 has to be enabled on the *service*, and for that to happen, the v4 feature-sets that the service is using has to be mirrored (and then tested/debugged) in v6, otherwise no real point to the test. 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... -igor
Current thread:
- Re: NAT Multihoming, (continued)
- Re: NAT Multihoming Simon Leinen (Jun 03)
- Re: NAT Multihoming Chris Owen (Jun 03)
- Re: NAT Multihoming Randy Bush (Jun 03)
- Re: NAT Multihoming Stephen Satchell (Jun 03)
- Re: NAT Multihoming Stephane Bortzmeyer (Jun 04)
- Re: NAT Multihoming Donald Stahl (Jun 04)
- Re: NAT Multihoming Iljitsch van Beijnum (Jun 04)
- Re: NAT Multihoming Donald Stahl (Jun 03)
- Re: NANOG 40 agenda posted Donald Stahl (Jun 03)
- Re: NANOG 40 agenda posted Igor Gashinsky (Jun 03)
- IPv6 transition work was RE: NANOG 40 agenda posted michael.dillon (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted JORDI PALET MARTINEZ (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted Igor Gashinsky (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted John Curran (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted matthew zeier (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted william(at)elan.net (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted matthew zeier (Jun 03)
- Re: IPv6 transition work was RE: NANOG 40 agenda posted JORDI PALET MARTINEZ (Jun 04)