[195934] in North American Network Operators' Group
Re: IPv6 migration steps for mid-scale isp
daemon@ATHENA.MIT.EDU (Lee Howard)
Sat Sep 23 03:22:48 2017
X-Original-To: nanog@nanog.org
Date: Wed, 20 Sep 2017 15:47:41 -0400
From: Lee Howard <lee@asgard.org>
To: Fredrik Sallinen <fredrik.sallinen@gmail.com>, <nanog@nanog.org>
In-Reply-To: <CAAGLZPFr7YTf-mzhmBFRwKswxGZMhH7sj==14ioCH+Hb78_Mbg@mail.gmail.com>
Errors-To: nanog-bounces@nanog.org
On 9/13/17, 8:08 AM, "NANOG on behalf of Fredrik Sallinen"
<nanog-bounces@nanog.org on behalf of fredrik.sallinen@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=E2=80=99ll need IPv6-only in
order to solve the IPv4 runout problem, though =E2=80=9Conly=E2=80=9D is likely to incl=
ude
translation.
>Where to start with IPv6? (core, edge or ...)
Web site.
Then core and peering.
Then push toward regional networks. You=E2=80=99ll 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=E2=80=99s 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 =E2=80=9CTCO of CGN=E2=80=9D and =E2=80=
=9CTCO
of IPv6=E2=80=9D to find it.
You should have very little incremental capital cost; that is, you
shouldn=E2=80=99t have to buy new hardware, because practically anything less tha=
n
ten years old can support IPv6. Whether it *does* is a question.
You=E2=80=99ll 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=E2=80=99s really the place to start.
The return on investment is that you don=E2=80=99t 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.
=E2=80=9CHey, boss, we=E2=80=99ll 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.=E2=80=9D
(Dozens of NANOGers laugh, a few cock their heads and think =E2=80=9Cmaybe=E2=80=A6=E2=80=9D)=
.
>How to identify address CPE and legacy application issues?
How do you do it now?
I=E2=80=99m guessing you test CPE that you provide, at least for basic
functionality.=20
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=E2=80=99s the best answer. Or you can put a NAT64 box in front of it (on
a VM, router, firewall, or load balancer=E2=80=94you don=E2=80=99t necessarily need new
hardware). But there=E2=80=99s 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=E2=80=99ll follow up
privately so this doesn=E2=80=99t 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
