Re: [v6ops] discussion of transition technologies

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 22 January 2018 20:37 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8D9127023 for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 12:37:35 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 mzgFvDQetwc0 for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 12:37:33 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357F5126D73 for <v6ops@ietf.org>; Mon, 22 Jan 2018 12:37:33 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id y26so7970602pfi.10 for <v6ops@ietf.org>; Mon, 22 Jan 2018 12:37:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9OeArAGerrvtPY4YkzVp47JyWnYP57zkpc/Mhv7fU+A=; b=P4dakyz2uZonh85rDWTNjyhKImMUDX3MYQ6CjkvS+fe44NGfLs64tHT0esZ1cZwYfq ZjYQZ75erPWEFlkozwxzl5RZOyLOBj827D7r0fDac9DuQqJW1ZsS8CE7MnbTuI/34VxZ bowfEjGbNHELQ08K9wF+/6495DSbWMjb+BcDstwcnTMk2cfTFdvb3Li4mm5BvqgS2qN8 a1s8s4kBgelmZvOWL33fvWXJ4Erp6PGzUmlgxM+HDksUxxIN/fGXfeqxShO/YST5/+MM XazOnVF22I2MwqQ5KrDQmj0kIR/SlHynmHg1n1GuGH0LEPl23ug5ON44k5W6jCNl8xXQ ZWaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=9OeArAGerrvtPY4YkzVp47JyWnYP57zkpc/Mhv7fU+A=; b=WLdMwsoQ2y/2DD/pFP8t140AwyMDZgAF5NY17L8O6qAwofagvSK00MHy6dRh7WiaaT orJTGAwiaU8J8CKYpH1MMjkklOPw+NHG11sBhVrYt41j+HRMKYFkUvJ18nVlVWQjOdpP RiN2A1DiuFPyh+zChmN4Al3AuRkWWxDO6CAxCb9GroA5yuWCeHB52IwnBmN8LK6gy7ZK V/2w5F5fbi8WvSiStQse7zuvS9TJz+Q+3X1S8s7WktEflpm+aHDqPWbl7jnbsmBB5ccC ChV0N7cSsihHZtkCsZfmRL+gR5beH4gtefnIcukTqQPlPfLlkqIh/U42z0tkb9EGxxIG +3ag==
X-Gm-Message-State: AKwxytfCnksejnEgrwlK/5FuqnrsRSVlhRQmn1zpWbrt5QLfHLnPITNR hw6iwT6Bq3B7Sz8rZNZuSbzFBg==
X-Google-Smtp-Source: AH8x224+yoPctedA0XcJhQMA4Gr0N9YXufgGkhmNsviJYdzX1541WkysXxCoxzvJIorkK4rUt+6Xuw==
X-Received: by 10.98.15.27 with SMTP id x27mr9124984pfi.197.1516653452301; Mon, 22 Jan 2018 12:37:32 -0800 (PST)
Received: from [192.168.178.30] ([118.149.102.251]) by smtp.gmail.com with ESMTPSA id b9sm16233144pgq.35.2018.01.22.12.37.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 12:37:31 -0800 (PST)
To: Fred Baker <fredbaker.ietf@gmail.com>, Ole Troan <otroan@employees.org>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
References: <D687BC24.92CC1%lee@asgard.org> <A6995969-0C03-4261-92F4-331206825130@gmail.com> <D29099E6-510D-41DA-B998-6BF15E9FDE7F@gmail.com> <1F7F8291-3023-4828-8C31-31CD379A58F5@employees.org> <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <f9e2c573-d684-c7c9-94ee-0d4ffd20e293@gmail.com>
Date: Tue, 23 Jan 2018 09:37:30 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <116BD6B6-0081-4C4A-BAC6-5E38B68ABB91@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/kD1cmZM3k9IjJXILmu_rBt0-KDE>
Subject: Re: [v6ops] discussion of transition technologies
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Jan 2018 20:37:35 -0000

After watching this debate, I'm asking myself why we want to anything
other than
a) watch the market deciding for itself, and
b) formally deprecate anything we decide is broken.

   Brian
On 23/01/2018 09:23, Fred Baker wrote:
> 
> 
> On Jan 22, 2018, at 11:17 AM, Ole Troan <otroan@employees.org> wrote:
>> What's the purpose of what you are trying to do?
> 
> This started out as a question among the chairs, triggered in part by an academic article that I can't share because it's not public yet. It lists 26 different transition mechanisms and tries to make recommendations, based in large part of recommendations we have made. The question started out as "can we narrow that to one such mechanism? Which ones are actually in use?" Now see the spreadsheet Lee shared, which comes from different data.
> 
> It sounds like Ole's data on 6rd needs to get reflected in Lee's spreadsheet.
> 
> After quite a bit of discussion, we think we had pretty much re-invented RFC 6180. The discussion isn't over, but I suspect we're close. So Lee asked for opinions from you guys.
> 
> And BTW, I suspect that dslite is a little long in the tooth for the same reason. The theory with both 6rd and dslite was/is that once there is a native path from here to there, even if the dslite configuration is still in the network it's unlikely to be used. That might be naive :-)
> 
> The big question among the chairs is "what is the real case for translation?" We see it in a variety of places, basically creating a way for IPv6-only devices or networks to talk with IPv4-only devices or networks, but wondering if there is a better way to proceed. My personal take is "it is what it is, no worse than IPv4/IPv4 translation" - not arguing for it, but considering it a fact of life until people become motivated to replace it with native systems and connectivity. YMMV.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>