Re: IPv6 transition work was RE: NANOG 40 agenda posted

[JORDI PALET MARTINEZ <jordi.palet () consulintel es>]

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