Re: [v6ops] Operational Consensus on deployment

Tore Anderson <tore@fud.no> Mon, 04 August 2014 18:51 UTC

Return-Path: <tore@fud.no>
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 257F11A0103 for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 11:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 jJFqzliFfZbL for <v6ops@ietfa.amsl.com>; Mon, 4 Aug 2014 11:51:37 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D3F1A00F2 for <v6ops@ietf.org>; Mon, 4 Aug 2014 11:51:37 -0700 (PDT)
Received: from cm-84.209.85.233.getinternet.no ([84.209.85.233]:58020 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tore@fud.no>) id 1XENM5-0001hK-3Q; Mon, 04 Aug 2014 20:51:33 +0200
Message-ID: <53DFD634.4020304@fud.no>
Date: Mon, 04 Aug 2014 20:51:32 +0200
From: Tore Anderson <tore@fud.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com>
In-Reply-To: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b9cjLRryQ1c2sTUIJHEGfMIJprY
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: Mon, 04 Aug 2014 18:51:39 -0000

* Fred Baker (fred)

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

Eerily good timing... I just started working on this again today, as it
happens. What I'm looking at now is two drafts, the one that's already
there for a single-translation network-only implementation, plus another
one describing an extension very similar to 464XLAT that would allow
NAT-incompatible and/or IPv4-only applications to be used in an
otherwise IPv6-only data centre.

However one of the things I was unsure about when I initially submitted
the draft was which WG was the most appropriate (sunset4 or v6ops).
Following the off-list discussion you, Marc, and I had back in November
2013, I thought the conclusion was sunset4. But now I see you saying
v6ops, so, uhm, now I'm no more certain than I initially was...

I'm in two minds about it, myself. The draft doesn't really describe
IPv6 operations per se, it deals more with the minimal backwards
compatibility glue necessary to provide service to IPv4 only users.
Score 1 for sunset4. On the other hand, an operator that wants to do
IPv6 today absolutely must have some form of IPv4 compatibility glue for
his offering to be commercially viable, thus, 1-1.

Tore