North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: JORDI PALET MARTINEZ
  • Date: Mon Jun 04 03:02:19 2007

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: <[email protected]>
> 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 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: <[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.
> :: 
> :: 
> :: 




**********************************************
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.