Re: [v6ops] discussion of transition technologies

Lee Howard <> Mon, 22 January 2018 21:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57EA712D7E4 for <>; Mon, 22 Jan 2018 13:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RwcRFnnEDhxx for <>; Mon, 22 Jan 2018 13:07:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7741112AAB6 for <>; Mon, 22 Jan 2018 13:07:18 -0800 (PST)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id w0ML7Fma007009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <>; Mon, 22 Jan 2018 16:07:15 -0500
Received: (qmail 22941 invoked by uid 0); 22 Jan 2018 21:07:15 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 22 Jan 2018 21:07:15 -0000
User-Agent: Microsoft-MacOutlook/
Date: Mon, 22 Jan 2018 16:07:09 -0500
From: Lee Howard <>
To: Brian E Carpenter <>, Fred Baker <>, Ole Troan <>
CC: " WG" <>
Message-ID: <>
Thread-Topic: [v6ops] discussion of transition technologies
References: <> <> <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <>
Subject: Re: [v6ops] discussion of transition technologies
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jan 2018 21:07:20 -0000

On 1/22/18, 3:37 PM, "v6ops on behalf of Brian E Carpenter"
< on behalf of> 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.

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.


>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 <> 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
>> 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 mailing list