Re: [v6ops] Operational Consensus on deployment

Ca By <cb.list6@gmail.com> Tue, 05 August 2014 03:10 UTC

Return-Path: <cb.list6@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 63FA81B278F for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 20:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 UtCu1dlgtK0n for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 20:09:58 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021F31B27A1 for <v6ops@ietf.org>; Mon, 4 Aug 2014 20:09:57 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id d1so508987wiv.15 for <v6ops@ietf.org>; Mon, 04 Aug 2014 20:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PtXqyKFOIT3OTZ4AMjKmsTzgLJ2qe+73XF7/M8FxZTM=; b=S0Gk9J++kkuM2LZSQxE/OvpYLAci7r+p1GzoZQdUt8nwM9yCpD6onE79HZKEMww2Kb 9Hxd5KdnGOGYjEvnHuecBXphmA8pBwxOJVHCGuLmioAD58fHMPyrmcSFIxd2Yct1x7eP AUodXTdLfh6t+3KOE5eeZcpl4GEDaTpNvoXkgyeGsYz/ZlYZav1s+PM0/bhABYZQl8h9 +NKOWeIi/g6qgc8LvoMzZAGDA1lrqNEvmI5KkLCjmyVgmFw128WWywP/MiiekcXuZxdv P6FoB+pqpXi0ewhFAiUETvzgqE9DkSyO2rhO+NZTXOFCq6gQfwrLMAQf3y1XqWxNO5Qi UK1A==
MIME-Version: 1.0
X-Received: by 10.194.222.197 with SMTP id qo5mr1420011wjc.78.1407208196402; Mon, 04 Aug 2014 20:09:56 -0700 (PDT)
Received: by 10.216.49.133 with HTTP; Mon, 4 Aug 2014 20:09:56 -0700 (PDT)
Received: by 10.216.49.133 with HTTP; Mon, 4 Aug 2014 20:09:56 -0700 (PDT)
In-Reply-To: <53DFEC6C.3010707@gmail.com>
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <DE860EBC-171E-46E7-A3B6-5E8B79A453CC@cisco.com> <53DFEC6C.3010707@gmail.com>
Date: Mon, 04 Aug 2014 20:09:56 -0700
Message-ID: <CAD6AjGRUWxT5XiNxMi_S5VgYtGMLb_FVHXN-ZfGpcY=geix15g@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c3a99aabf50b04ffd9304b"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Lv1ME_EqhcBHXTviCp5GiPs5LVY
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: Tue, 05 Aug 2014 03:10:00 -0000

On Aug 4, 2014 1:26 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
wrote:
>
>
> > 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.
>

Why?

I was told the same thing about 464xlat, we did not need another solution.
If the ietf held the line against double translation i believe there would
be exactly 1 ipv6 cellular provider in the world (verizon).

With 464xlat, afaik, there are globally 3 cellular providers that offer
default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ).

It does not matter if the cat is white or black, it matters that it catches
mice.

CB

> (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
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops