IPv6 migration steps for mid-scale isp

Wed Sep 20 19:47:41 UTC 2017

On 9/13/17, 8:08 AM, "NANOG on behalf of Fredrik Sallinen"
<nanog-bounces at nanog.org on behalf of fredrik.sallinen at gmail.com> wrote:

>Hello,
>
>Recently we have decided to start IPv6 migration in our network. We
>have ~1K BNGs and connecting our customers to network using PPPoE.
>I'd be interested in hearing from the technical community about their
>experiences and recommendations on this process. I'm wondering:
>
>Shall I go for IPv6-only deployment or dual stack?

Dual-stack is the best way to get to IPv6-only. You’ll need IPv6-only in
order to solve the IPv4 runout problem, though “only” is likely to include
translation.

>Where to start with IPv6? (core, edge or ...)

Web site.
Then core and peering.
Then push toward regional networks. You’ll need IPv6 into at least the
part of your data center does provisioning and monitoring.
Then start pushing to customers.

>What are the best practices for ISPs?

Lots of documents exist. Here’s one: https://tools.ietf.org/html/rfc6782

>What are the costs and return on investment?

Oh, I have so much to say on this topic. Search for “TCO of CGN” and “TCO
of IPv6” to find it.
You should have very little incremental capital cost; that is, you
shouldn’t have to buy new hardware, because practically anything less than
ten years old can support IPv6. Whether it *does* is a question.
You’ll have some opex network engineering costs in testing and deployment,
which might be high(ish) if you have a lot of different equipment in your
network. Your biggest cost is likely to be the development labor to update
your IPAM, provisioning systems, management, logging, and tech support
tools to be able to store and use the new address format. Development is
likely to be what takes longest, so that’s really the place to start.

The return on investment is that you don’t have to spend $15 to buy an
IPv4 address for every new user you have to sign up. Or $25 per address in
2019, if trends continue. [1]
Depending on how happy you are with your transition mechanism (NAT64,
464xlat, MAP, etc.) you could, instead, sell off those IPv4 addresses.
“Hey, boss, we’ll turn up 10,000 new customers in 2019, right? We can
either spend $250,000 to buy addresses, or we can put 10% of our customers
behind NAT64 (or whatever) and sell their IPv4 addresses for $25 each.”
(Dozens of NANOGers laugh, a few cock their heads and think “maybe…”).

>How to identify address CPE and legacy application issues?

How do you do it now?
I’m guessing you test CPE that you provide, at least for basic
functionality. 
Some bugs still get past you. A few customers call, you notice a trend
among customers with X CPE that they have a problem in the area where you
just rolled out IPv6. You roll back IPv6 in that area or (hopefully) just
from those devices, and put that CPE in the lab and test the heck out of
it.

For legacy applications, it depends on the application. If you can update
it, that’s the best answer. Or you can put a NAT64 box in front of it (on
a VM, router, firewall, or load balancer—you don’t necessarily need new
hardware). But there’s also the entire rest of the old Internet: you will
probably want to have some kind of transition mechanism in place.

I know folks who specialize in transition mechanisms; I’ll follow up
privately so this doesn’t look like a sales pitch on the list.

>
>Fredrik
>

Lee

[1] Charts, using IPv4auctions.com (Hilco Streambank) data:
http://www.wleecoyote.com/blog/2017prices.htm