|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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
|