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

  • From: michael.dillon
  • Date: Sun Jun 03 18:03:26 2007

> 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 
> rotation, it's going to be figuring out how to take 
> everything that we use for, 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 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