IPv6 transition work was RE: NANOG 40 agenda posted

Sun Jun 3 23:16:06 UTC 2007

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 AAAA 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: <michael.dillon at bt.com>
:: > Responder a: <owner-nanog at merit.edu>
:: > Fecha: Sun, 3 Jun 2007 23:01:57 +0100
:: > Para: <nanog at nanog.org>
:: > 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.
:: 
:: 
:: 