Re: [v6ops] discussion of transition technologies

Mark Smith <> Mon, 22 January 2018 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAD30124D6C for <>; Mon, 22 Jan 2018 14:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ONoGJX77r0Ne for <>; Mon, 22 Jan 2018 14:17:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65ADE127876 for <>; Mon, 22 Jan 2018 14:17:00 -0800 (PST)
Received: by with SMTP id e125so5941734vkh.13 for <>; Mon, 22 Jan 2018 14:17:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3xOtqkAGDSp7aS6C5LDnEpxsc4nFD9bWL66PUETC7Sg=; b=k/UiDQvUQk9IPrV9jNftoH9mMioVHh18ytE6Lpq1BZuCltbZTiTt9owCyIrlatnK2e adlq+uxLp+DmR/NXsfFfSmL4I4c5EeUiWGym8imdTCKMyiSiJipSAi3lfsvLTiKk2Isr hsu8mNVohZwphq7haM667f9s2r1fPh1mCOKfmqw8SrJwMkqb/eCJlP1KZ5/aIBzgxKQa P50pdw1MdkrhUEhcSesyB6S73YxdW9zq7MTcNL8ayYwt+nQP2DaceVVmkQDfL36sveXS 2b5bmEVRn6ya7hom5AI03kli6M213ytU8I8vZ9QFVzJFOyHHfWCliwSkcZIcAlSZM0NT Fo3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3xOtqkAGDSp7aS6C5LDnEpxsc4nFD9bWL66PUETC7Sg=; b=C1wk1Q9WwEQ+Owwt8snMBrapxcd84XtuNuUuJRoWfePbjnLVcheStjllTrm28Zn73k SuTTf3h9/qsT9CRxM4ZZupcPoKisyRh67L6cz1qJu4Gy1wOxlTHQ/0h4Qx5a4M6x00d7 0eWacKfnp6iuB/t/pnzLdVOPUaP8mRIar2INRImYzYWBQ18hQuvsDNfnaM17xeEge+Hy Kc+VTLJh6CBmsccBOIYzPGf8aAjQq9FhpJtAainkllb86mSPAUphQRMRBqsAUDAd9vpV ZT23Szi5aRtb/fblFyiP+twbGB49qypgKle+T+VHMwhTxsHL04/jEFu+kxxjXBMorwZ0 WBHQ==
X-Gm-Message-State: AKwxytfJa2Th9v0t6pJ5qFE9ka6B8qu8uzhI4zy+Y1zqrHmYR3Y8yTMX dFkeBgMjfHi7IiERK6X5kVPk9Nd2/igXBkUxf4U=
X-Google-Smtp-Source: AH8x2243rYEEHORElFNaTtNKl+bkl/ZKukWKdaD+ZT7aTFpa0qYEOLp3rlnRpu0C5cOM8e74kRRXoA5rKGUXk0GyH9s=
X-Received: by with SMTP id n73mr284999vkf.3.1516659419315; Mon, 22 Jan 2018 14:16:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 22 Jan 2018 14:16:58 -0800 (PST)
Received: by with HTTP; Mon, 22 Jan 2018 14:16:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Mark Smith <>
Date: Tue, 23 Jan 2018 09:16:58 +1100
Message-ID: <>
To: Brian E Carpenter <>
Cc: Fred Baker <>, Ole Troan <>, " WG" <>
Content-Type: multipart/alternative; boundary="001a114dd9d4ef0356056364c9f8"
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 22:17:04 -0000

On 23 Jan. 2018 7:37 am, "Brian E Carpenter" <>

After watching this debate, I'm asking myself why we want to anything
other than
a) watch the market deciding for itself, and

I think with so much choice, the market has trouble making a choice. It
becomes less risky to make no choice (meaning no IPv6 deployment at all)
compared to the risks of making the wrong choice.


b) formally deprecate anything we decide is broken.

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