Re: [v6ops] Operational Consensus on deployment

Mark Andrews <marka@isc.org> Thu, 28 August 2014 02:00 UTC

Return-Path: <marka@isc.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFCF1A0089 for <v6ops@ietfa.amsl.com>; Wed, 27 Aug 2014 19:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.569
X-Spam-Level:
X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 gcycEHFyI5Pf for <v6ops@ietfa.amsl.com>; Wed, 27 Aug 2014 19:00:25 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2471A00A6 for <v6ops@ietf.org>; Wed, 27 Aug 2014 19:00:25 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 09E491FCB5C; Thu, 28 Aug 2014 02:00:22 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BD02016006A; Thu, 28 Aug 2014 02:02:59 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5A48916005D; Thu, 28 Aug 2014 02:02:59 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7B7761DA70F7; Thu, 28 Aug 2014 12:00:19 +1000 (EST)
To: James Woodyatt <jhw@nestlabs.com>
From: Mark Andrews <marka@isc.org>
References: <DE860EBC-171E-46E7-A3B6-5E8B79A453CC@cisco.com> <53DFEC6C.3010707@gmail.com> <CAD6AjGRUWxT5XiNxMi_S5VgYtGMLb_FVHXN-ZfGpcY=geix15g@mail.gmail.com> <53E06AC9.9010908@fud.no> <4F7D76F6-BD81-453B-94DC-A3C3DFF68505@delong.com> <8600C096-37D0-4651-92C1-BCFDBA674433@nominum.com> <CAD6AjGTBfyT-zNDJtBKCNtRxd=Hi07678Sr_-HgSGYbjAiF3Tg@mail.gmail.com> <C5281716-DC04-42E6-AC82-0D53E5DA0284@nominum.com> <53E1236A.605@fud.no> <m1XEkJJ-0000BuC@stereo.hq.phicoh.net> <20140805195402.GO51793@Space.Net> <m1XElwg-0000BbC@stereo.hq.phicoh.net> <D00834AF.68B6C%Lee@asgard.org> <CAD6AjGQJ3PXpGkk9Cd4d-MhExZ9QrpiseyAqPqmpXzQ-HCyDwQ@mail.gmail.com> <CAKD1Yr2=dMg6sua+9v28t173TQVYet6pDU7Xv6RWkbGjqA1ziA@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303B7DB43@UK30S005EXS06.EEAD.EEINT.CO.UK> <20140820003344.23DE61D105DD@rock.dv.isc.org> <D7A0AFA1-86F3-4658-B3BB-B8C4721843DF@delong.com> <CADhXe53yucmTprtF+vqsPsgqF+4-w6RAAqoN2SsFatccZNT=6g@mail.gmail.com> <35E70324-B972-4411-8CD3-BC07EA553859@cisco.com> <CADhXe53-BRyGjNUOqMYvpHwhS35rr9xFQWOL7bOwnEj-PZoT2g@mail.gmail.com>
In-reply-to: Your message of "Wed, 27 Aug 2014 11:12:41 -0700." <CADhXe53-BRyGjNUOqMYvpHwhS35rr9xFQWOL7bOwnEj-PZoT2g@mail.gmail.com>
Date: Thu, 28 Aug 2014 12:00:19 +1000
Message-Id: <20140828020019.7B7761DA70F7@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eiL92VEpqQgXJddasTdKHEWazkY
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Operational Consensus on deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 02:00:32 -0000

In message <CADhXe53-BRyGjNUOqMYvpHwhS35rr9xFQWOL7bOwnEj-PZoT2g@mail.gmail.com>
, James Woodyatt writes:
>
> No, actually— it never needs to be feasible to turn off IPv4.  Ordinary
> people, the users of Internet applications, don't really see any need to
> augment IPv4 with IPv6.  And they never will until the utility of the IPv4
> Internet begins to degrade noticeably in comparison to the IPv6 Internet.

CGN significantly degrades IPv4 for some as you no longer have working
port forwarding, a semi static public IPv4 address, and access to
protocols other that TCP, UDP and ICMP.

PCP still needs the CPE to be upgraded which hopefully will include IPv6
support.

> If people are never exposed to the idea that "using $APPLICATION is full
> of lose because IPv4, use IPv6 instead," then people will never have any
> incentive to stop using IPv4 and start using IPv6.  So long as IPv4
> continues to be 1) an essential service and 2) functionally equivalent to
> IPv6 at the level of application visibility, there is no actual need to
> solve the IPv6 access problem, because application users don't actually
> need it.
>
> If operators want ordinary people to migrate from IPv4 to IPv6, they might
> try offering IPv6-only service at discount prices— which would position
> IPv6 as the protocol for second-class citizens who can't pay premium
> prices
> for the first-class Internet that rich celebrities enjoy between bites of
> caviar.  Or they can offer dual-stack service and provision their networks
> so that CGN44 boxes are the peak-load IPv4 bottlenecks, which would
> position IPv4 as the protocol for second-class citizens who can't afford
> to> upgrade to the latest gear.  Which of those strategies do we think
> provides more incentive to upgrade to IPv6?

* Just fail 10% of connection attempts through the CGN44.
* Only allow X table entries per customer, where X decreases every month.

I think the first thing they want is to get IPv6 capable CPE devices
installed and IPv6 enabled on them.  When +50% of traffic will
switch to IPv6 immediately you get significant saving through not
having to provision the CGN44 to support all the sessions that are
going over IPv6.  Less IPv4 address are needed.  Less boxes are
needed.  With CGN44 its simultaneous sessions per IPv4 address which
is a limiting factor.

You get a bigger pool of IPv4 which can be handed out to those
customers (domestic and commercial) that really still need a public
IPv4 address possibly for a addition cost.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org