Re: [v6ops] discussion of transition technologies

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 22 January 2018 21:23 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 DDF5312D7E8 for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 13:23:28 -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 Jk8R9TgE5Jbs for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 13:23:26 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 8783912D7E2 for <v6ops@ietf.org>; Mon, 22 Jan 2018 13:23:26 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id k68so8081103pga.3 for <v6ops@ietf.org>; Mon, 22 Jan 2018 13:23:26 -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=be1rMf0SDSrlLOOsPOZap1wXNhN68xqzfwfHfUpyXfA=; b=R0hVWulahGJKUUb2P4xKPbzAVGNJWnROVALzVvAK+whdZovO9YxmBIMp7v3yq2QJLZ bSZUlxj9beWDYtupchCe1N29/kPClOOKj2Sj/dJ3ZzLjKEpE1NRCMRb03plSaotNbmz7 hTfPfJEoUOasJzAa4+kHSFuDtGIF3M5MtHFHrxyEwesGBfQXLRKI1qBwMRXXfIZVicf7 ZJEsDHZVP3KR8t4ND+DQiYVFLmDnJCifqtdemhfyKSiW+q/KV+/yRYP1DU8chCS7f+0w tV3/gIgHQR7SjgoAls2IENPkRyx2/4OgPEHlpvLLrtqajNUlibf/AR4zS+rVf47oZDKc cUQg==
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=be1rMf0SDSrlLOOsPOZap1wXNhN68xqzfwfHfUpyXfA=; b=Zq0koxUs+R6oBnNdsG1261fCcOxqK9a/i+/Jc+j3Az83gPZl7uMrp18MVOo/NPErCx vKZ63SFJ87CNxv+X7t4IL97IFDMXAxbWHSqg/OizZW/vEjcrL3l/ZHUQilJrMuLmvhd+ jt1u9nHcQ+mUOHIOg26KIMdmEeKAdF6xltOXGj6HlNf+Y77UVKX/ESdgG2RH/aYUh0E+ NjUazNG5ZdC8lES7pobTmWUM5r7y53vwUDavPcvyPX3Yf+gyjKGGuBL+vEQRh/85a3DR zMflJ5y9qJ4MpVDbkqoqe7PU7PXhHZptrIw+JPIu0vP3TyfgzuTzatVMhkOmZQ3vPZuI Jxug==
X-Gm-Message-State: AKwxytdw/YkoTJHNGlTXhR5u7nl5x3mxlvoKpABjPgs14mrclSf5v+6j FStiTMgZrGs8m+Sewyn7tyOIxg==
X-Google-Smtp-Source: AH8x225MJ50S0Q9zJG/1sVWx445cjh8fNSgWO1F5vwXpTaGaB9RBVCFMToGS0J518s02Wr4q2+1cxQ==
X-Received: by 2002:a17:902:7716:: with SMTP id n22-v6mr4158262pll.388.1516656205737; Mon, 22 Jan 2018 13:23:25 -0800 (PST)
Received: from [130.216.38.21] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.21]) by smtp.gmail.com with ESMTPSA id c29sm1785476pfd.172.2018.01.22.13.23.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 13:23:24 -0800 (PST)
To: Lee Howard <lee@asgard.org>, 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> <f9e2c573-d684-c7c9-94ee-0d4ffd20e293@gmail.com> <D68BB9BB.964BB%lee@asgard.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <876fa6df-bf73-13c5-8427-a9bc2c3100b3@gmail.com>
Date: Tue, 23 Jan 2018 10:23:24 +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: <D68BB9BB.964BB%lee@asgard.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/68ZRMg9U5TuUoHupAcbTUwluXXU>
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 21:23:29 -0000

On 23/01/2018 10:07, Lee Howard wrote:
> 
> 
> On 1/22/18, 3:37 PM, "v6ops on behalf of Brian E Carpenter"
> <v6ops-bounces@ietf.org on behalf of brian.e.carpenter@gmail.com> wrote:
> 
>> After watching this debate, I'm asking myself why we want to anything
>> other than
>> a) watch the market deciding for itself, and
> 
> We are the market. :-)
> 
> As Fred describes, a lot of market participants (myself included) are
> overwhelmed by the number of transition mechanisms, and I have heard from
> quite a few people (myself included) that I could not possibly investigate
> 26 different technologies well enough to understand the trade offs between
> them, and some therefore become paralyzed. RFC6180 "Guidelines for Using
> IPv6 Transition Mechanisms during IPv6 Deployment” is fine as far as it
> goes, but it doesn’t consider all of them, and was published before
> 464xlat and MAP.
> 
> I don’t know that we need to publish an update to RFC6180, but maybe we do.

Has RFC6180 proved useful to people? If so, update it by all means.
 
> For my own use, I get asked a lot what transition technology people should
> use. I’d like to know that my answers are good.

Understood. A decision tree would be ideal. I'm just not sure that this
is the ideal place to develop it.

    Brian

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