[v6ops] Operational Consensus on deployment

"Fred Baker (fred)" <fred@cisco.com> Mon, 04 August 2014 16:55 UTC

Return-Path: <fred@cisco.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 5D18E1A0019 for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 09:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -116.502
X-Spam-Level:
X-Spam-Status: No, score=-116.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 OEZfgIjCnoGz for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 09:55:46 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33961A003A for <v6ops@ietf.org>; Mon, 4 Aug 2014 09:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4072; q=dns/txt; s=iport; t=1407171346; x=1408380946; h=from:to:cc:subject:date:message-id:mime-version; bh=GBa8F3+LYEVTbvPk83vaefiwjUFR1rXSNiow0/efv1U=; b=WVUahjpkRiRi2nlNz0nDPUGaaWKuQduJLgxczmFdqCT1OI7kehlGT3iC SBCa4jl0AU0YnePCIgyd/vBG+dCUvgcPPwhaqPm1sgS7xP+HbfmQ9Nqul m1l1neSDmcCNofBUZ5Vc86rLrYPEtEgeTBWjIfapWl4LVwEqSj287ozmH I=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkAFANS531OtJA2M/2dsb2JhbABbgw1SVwS0OpdxCodKgRIWd4QFBXkSASBgJwQOBQ4NiBMDEQ2+NAqGZhePTII/UySBHAWEfwKJdoQMgUkDhzeBVJMLg01sgUY
X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="asc'?scan'208";a="66349516"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP; 04 Aug 2014 16:55:45 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s74GtjS1011262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 16:55:45 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 11:55:44 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Ross Chandler <ross@eircom.net>
Thread-Topic: Operational Consensus on deployment
Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8g==
Date: Mon, 04 Aug 2014 16:55:43 +0000
Message-ID: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.115]
Content-Type: multipart/signed; boundary="Apple-Mail=_5CCCF3C0-42F5-450E-9D71-E287622E7D6C"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sr7DlWt7GxiOclkFL3kDL2uF5_8
Cc: IPv6 Ops WG <v6ops@ietf.org>, "tore.anderson@redpill-linpro.com" <tore.anderson@redpill-linpro.com>
Subject: [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 16:55:48 -0000

I changed the subject line.

On Aug 4, 2014, at 9:18 AM, Ross Chandler <ross@eircom.net> wrote:
> Section 7, discussions,  says “dual-stack deployment is recommended in most cases”. Is that still the consensus position?  Going straight to single-stack IPv6 is looking very viable now when the UE supports a method of providing translated IPv4 access over the IPv6 PDP/PDN connection. 

I would agree that there are a number of operators moving in that direction - DTAG Terastream, Google, Facebook, and several mobile operators come quickly to mind. The number of operators that still don’t have a customer-facing IPv6 offering still dwarfs them, and the IETF has not itself changed that position. So I would say that we have not changed our fundamental consensus - and at the same time agree that it isn’t as steady as it once was. There are cracks in the glacier.

Let me say this, though. The fundamental question that we have to answer, if we want to change the consensus, is (1) how we safely move a business from IPv4 to IPv6, shutting IPv4 down, and (2) how we deal with the residual IPv4 Internet. As with 464xlat or softwire's MAP, the latter comes down to some variation on translation and/or encapsulation. What I would like to see - consider this an invitation to an operator or an operator and a vendor that have implemented it and want to collaborate - is:

   - a short draft, counterpart to RFC 6540, stating a change in the operational consensus toward IPv6-only deployment
   - a practical approach on “how to get there” (probably more than one draft, addressing differing operational requirements)
   - a practical translation solution (possibly more than one draft)

I still tend to think that dual stack is the most reasonable “how to get there” approach; you have to have a running IPv6 network to move customers to before you can shut down the IPv4 network. The question is how long IPv4 stays up once you have a viable IPv6 network. If someone has a better idea, that is something to discuss.

I’m copying Tore, because I think http://tools.ietf.org/html/draft-anderson-siit-dc might very well be that “practical translation solution” for at least some environments. For an enclosed environment such as a data center, it enables the implementation of an IPv6-only environment, maintains IPv4 access to it, and maintains geolocation capabilities across that translation. At the point where the business requirement for IPv4 accessibility falls off, the translator simply becomes a vestigial capability, as opposed to requiring a dramatic and costly change. That seems pretty attractive. I’d invite discussion on that and on the draft (which is long expired, but Tore could resurrect it as draft-anderson-v6ops-siit-dc if he wanted to). If it now has a consensus behind it, publish as an RFC.

We would also need recommendations for residential broadband, which John Brzozowski might be in a position to make, and for enterprise networks, which someone from Google or Facebook might be in a position to do, or someone else.

I’ll channel Lorenzo, here. Lorenzo, correct me if I get this wrong. We want any statement along these lines to come from someone that has implemented it in their network.