Verizon DSL moving to CGN

Mon Apr 8 14:58:18 UTC 2013

On 4/8/13 7:23 AM, Jack Bates wrote:
> On 4/8/2013 7:20 AM, Tore Anderson wrote:
>> BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
>> address or even a prefix to the subscriber, thus also taking away the
>> need for [srcport-restricted] NAPT44 in the CPE.
>
> The problem is NAPT44 in the CPE isn't enough. We are reaching the 
> point that 1 IPv4 Address per customer won't accommodate user bases.
>
That happened a long time ago. I realize the people like to think of 
wireless providers as different, they really aren't. A big chuck of our 
mobile gaming customers come to us via carrier operated nat translators. 
Some of them now come to us via ipv6, most do not.
> The larger issue I think with MAP is CPE support requirements. There 
> are ISP layouts that use bridging instead of CPE routers (which was a 
> long term design to support IPv6 without CPE replacements years 
> later). CGN will handle the IPv4 issues in this setup just fine. Then 
> there are those who have already deployed IPv6 capable CPEs with PPP 
> or DHCP in a router configuration which does not have MAP support. 
> Given the variety of CPE vendors that end up getting deployed over a 
> longer period of time, it is easier and more cost effective to deploy 
> CGN than try and replace all the CPEs.
>
> Given US$35/CPE, cost for replacements (not including deployment 
> costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so 
> costly.
>
> The only way I see it justifiable is if you haven't had IPv6 
> deployment in mind yet and you are having to replace every CPE for 
> IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which 
> the customer pays for if they wish IPv6 connectivity(or during 
> whatever slow trickle replacement methods you utilize). While waiting 
> for the slow rollout, CGN would be an interim cost that would be 
> acceptable. I'm not sure there is a reason for MAPS if you've already 
> deployed CGN, though.
>
> I am sure Verizon did a lot of cost analysis.
>
> Jack
>