Re: [v6ops] Operational Consensus on deployment

Owen DeLong <owen@delong.com> Tue, 05 August 2014 01:15 UTC

Return-Path: <owen@delong.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 D8E901A0ACF for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 18:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.992
X-Spam-Level:
X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 ruoVLKFd6Gl7 for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 18:15:07 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2091A0ACD for <v6ops@ietf.org>; Mon, 4 Aug 2014 18:15:07 -0700 (PDT)
Received: from [192.168.1.62] (ip72-199-16-177.sd.sd.cox.net [72.199.16.177]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s751CnEu004133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Aug 2014 18:12:52 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s751CnEu004133
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1407201174; bh=hKE37Tu1Se4zZUvls+rXtFjh8QM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=F1wlOsg04mA4mSk/f0ftay8/nMC8/pyo5qrAltqq920mGnPlhzsHmzkK1FbMPjtY9 R0y4Jl0UxrehI58Q/jiH6UmrF4pcW2N/cELsTtfZ3+XQOGn/h6FUyidqWxR6fA8dYD GDXpVmw/Q2cQu07b77KoVyFgN0s5Qk1cKeiCkFO0=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com>
Date: Mon, 04 Aug 2014 18:12:41 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F245536-5BBC-4E6E-AA7D-2B6F7C01F434@delong.com>
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com>
To: "Fred Baker (fred)" <fred@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 04 Aug 2014 18:12:54 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DFHoyo_fV73ZkjPFA_5fGdcp3OU
Cc: IPv6 Ops WG <v6ops@ietf.org>, "tore.anderson@redpill-linpro.com" <tore.anderson@redpill-linpro.com>
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 01:15:12 -0000

On Aug 4, 2014, at 9:55 AM, Fred Baker (fred) <fred@cisco.com> wrote:

> 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. 


I believe that Dual Stack is still the best way forward in most cases where there are existing IPv4 addresses.

In the case where IPv4 addresses are unavailable, I think there is no clear winner and it is very situational and subjective to choose an appropriate translation/mapping solution for the given situation. Ideally, we should be working as hard as possible to get to a point where the solution to a lack of IPv4 addresses is clearly ideally IPv6 only.

Owen