Re: IPv6 deployment [was Re: Recent Internet governance events]

Ted Lemon <ted.lemon@nominum.com> Fri, 22 November 2013 16:59 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E11AE3E8 for <ietf@ietfa.amsl.com>; Fri, 22 Nov 2013 08:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhLRPKjqLEXL for <ietf@ietfa.amsl.com>; Fri, 22 Nov 2013 08:59:34 -0800 (PST)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7D44F1AE1B6 for <ietf@ietf.org>; Fri, 22 Nov 2013 08:59:34 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUo+Nb3MEdrVFRVuWhzL6MJC+HSbRw/tB@postini.com; Fri, 22 Nov 2013 08:59:27 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 652051B814B for <ietf@ietf.org>; Fri, 22 Nov 2013 08:59:27 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5D38F190043; Fri, 22 Nov 2013 08:59:27 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 08:59:20 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: IPv6 deployment [was Re: Recent Internet governance events]
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <20131122164627.39A7F18C0E8@mercury.lcs.mit.edu>
Date: Fri, 22 Nov 2013 11:59:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <C77D47FD-0792-4E22-B8AF-8393965C8AC2@nominum.com>
References: <20131122164627.39A7F18C0E8@mercury.lcs.mit.edu>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
X-Mailer: Apple Mail (2.1822)
X-Originating-IP: [192.168.1.10]
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2013 16:59:36 -0000

On Nov 22, 2013, at 11:46 AM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>> CGNs are expensive. Why would people prefer to maintain them if the
>> IPv6 infrastructure was working? 
> 
> Cheaper than customer service calls.

That's almost certainly true now.   I'm not talking about now.   Really, the big problem with CGNs is that they don't scale—this is why lw4over6 and MAP represent a significant and useful innovation.

What I expect to see happen in the market is that in the next decade, CGN will start to seem old-fashioned, and more and more what will be deployed will be stateless port-sharing NAT hardware in the core, supported by stateful NATs at the CP, just like we were doing before the CGN idea got popular.

The nice thing about stateless NATs in the core is that they can be scaled up and down according to need.   So as more traffic is carried over the native IPv6 network, you can start switching off boxes in the core.   You can track the demand, so you don't switch off boxes that are needed.   You can even goose the switchover by running your IPv4 NATs closer to capacity, forcing traffic that could go over either transport to go over v6, because it's working better, and Happy Eyeballs can tell.