Re: [v6ops] Operational Consensus on deployment

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 04 August 2014 20:26 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 A2CFB1A02A0 for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 13:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Gcg1CYGkFHjq for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 13:26:22 -0700 (PDT)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8861A0201 for <v6ops@ietf.org>; Mon, 4 Aug 2014 13:26:22 -0700 (PDT)
Received: by mail-pd0-f181.google.com with SMTP id g10so10213584pdj.40 for <v6ops@ietf.org>; Mon, 04 Aug 2014 13:26:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NEMO2uGUZwTH+KymJ/PqPwLitioNtHyRlaR1SNMJLhk=; b=Ivlgo2SYNT+KdhsoWH4KGR7vt4JUyhoNXa3HIDvPWnr7DB7vxYPIh91QdC556p+31q YMo/FOffrHQ1L48KSiuKBT28DhO8XW+a2RP2ZbNmr33cEiLfCLcQKlr8rCXkDdqiRFjJ iSJTOVzbfiw8ROELzq955gHcMp5CjhEXf5wjkIDcn6U4g8y4jjok4RzG4yc4KgKpq4px 6rhG88ZRTZ4E/NJ4MR+qsJytUZty8Dus109iBkI6sbqpLIB0ylt6M43nQIaHu7LHlQLr 5UpyHOzHMSyP1O4z+1/HKlAmNpD5vYT9Sx5dokdOF6BEaa6uYeV8wLra2tK8LUmyRbXl m7YQ==
X-Received: by 10.70.134.165 with SMTP id pl5mr15305071pdb.20.1407183981846; Mon, 04 Aug 2014 13:26:21 -0700 (PDT)
Received: from [192.168.178.23] (202.195.69.111.dynamic.snap.net.nz. [111.69.195.202]) by mx.google.com with ESMTPSA id et1sm18366880pbc.39.2014.08.04.13.26.19 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 13:26:21 -0700 (PDT)
Message-ID: <53DFEC6C.3010707@gmail.com>
Date: Tue, 05 Aug 2014 08:26:20 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <DE860EBC-171E-46E7-A3B6-5E8B79A453CC@cisco.com>
In-Reply-To: <DE860EBC-171E-46E7-A3B6-5E8B79A453CC@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AXiLau7gacR8pxINd3oGc2eDTnw
Cc: IPv6 Ops WG <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
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: Mon, 04 Aug 2014 20:26:23 -0000

> My point in bringing this up is not that it is “useful in an IPv6 network” that might also be running IPv4 in parallel. It is that it seems useful to me in moving toward and IPv6-*only* network. Ross suggests that he sees conceptual movement - First they ignore you, then they laugh at you, then they fight you, and then you win. We may, Ross suggests, be approaching stage 4. It may be useful for us as a working group to lay out the game plan for that movement - not just to document IPv6 operational practice, but to help the IETF determine whether the dual stack consensus has changed or is changing, and help operators figure out how to turn IPv4 off without individually shooting their toes off. This would be part of that game plan.

Well, I think the operators that moved early into genuine dual
stack operation have no reason to regret it. I'm a happy customer
of one such. On the other hand it seems that other operators are of
the opinion (probably unprovable) that providing the illusion of dual
stack service to the customer over an IPv6 infrastructure is cheaper.
In any case the customer ends up with NATted IPv4 service in most
cases, so at user level it doesn't really matter.

I think we should probably not express a preference either way. It
seems like a decision for each operator to make individually. What we
probably should do is stop inventing more solutions.

(In parenthesis, I've never seen sunsetting IPv4 as a real problem.
One day somebody will notice that there are no more IPv4 packets. But
that is many years in the future.)

    Brian