Re: [v6ops] discussion of transition technologies

Fred Baker <> Sat, 20 January 2018 00:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BFD1129C6E for <>; Fri, 19 Jan 2018 16:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 4JwZRlSKMVfZ for <>; Fri, 19 Jan 2018 16:22:19 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36BDD120713 for <>; Fri, 19 Jan 2018 16:22:19 -0800 (PST)
Received: by with SMTP id z48so3037182wrz.6 for <>; Fri, 19 Jan 2018 16:22:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0UoAOGncSxHkQO796ayJwi7dFk+0nTmEA9y73gFsNis=; b=VGzRnb1UwYUrnB9kC2FkUjqe2uZ4+DDhde3I5jfE01IouBqww+h9DW4p35oDg8pQdz zTJviuzwhJ1Z2OM2HJl2By8CTbwfq4ULkOlG7kKNPgQ2g1KRYWPhFh6JPWIWeyzCZq/D 6KSahuJk+n+eaQgvaQx8K5m7kIdipfD/3F75EXKVIwn5hAMdLTGgz5rgRXUwrL61iVLf 7w9iYK+HWFeFOgtlvVXrONaEPWCMdlJfFIPY9riI5wuaQfPIQa38IMau+N6JUGSg7zC8 qqsOJcHNiN4g3RTgktUnUr1Yhrkh1GWpSxMV7YrLbMaUk8Mtw50OkPvTzgpKAstpyBaA S3/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0UoAOGncSxHkQO796ayJwi7dFk+0nTmEA9y73gFsNis=; b=iR6+mi90A/OoZXUvDOwL2zyqauBzGS4b0q1AwDrY2HahtKYfzyT3iV6z+l3L29mHho nTo+JE9gNkPu9Lq84YZE9bbOt7jxPlstYn/L2Rmtzr18WwLMa6CNOVqBxBb0FBc3zw3L 7OMQlFDv64ayI+DauFtCUXKTCsbq1t7Zz+L/D+TtL40CIiQXHhrlbKxfV649e8nzSWwM foUVNvrLtUX1HxuRx6qTgSA0RoSD/seWnm7ruRwV1/K0/qROgOngQBoM1fgucMhSRUkS ks3EW56p1Ou6YhleHaZeG0Wspi1B6TA6uIZ+oWexioHZNk0djc+FhkSw9dWtpfj7vbV+ LLUQ==
X-Gm-Message-State: AKwxytcWz3qTWaoM9eaokNHNUQv5H0hMupwbQZBOKZsxBAi/eOj4F/q/ 53ovukgHjDt1N/kGnllc8Ws=
X-Google-Smtp-Source: AH8x226QNK/MhbDCRhZGFxBUtrCidINJf90b6JU3SDQAGgC9PQkGhpFA7F55Wm6lL3iIOfTSX/wvdw==
X-Received: by with SMTP id k16mr183227wrc.100.1516407737322; Fri, 19 Jan 2018 16:22:17 -0800 (PST)
Received: from ( []) by with ESMTPSA id w14sm8778399wrc.63.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 16:22:16 -0800 (PST)
From: Fred Baker <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_739D0947-5A4D-4737-A9AF-E80A65A97584"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Fri, 19 Jan 2018 16:22:12 -0800
In-Reply-To: <>
To: Lee Howard <>
References: <>
X-Mailer: Apple Mail (2.3445.5.20)
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: Sat, 20 Jan 2018 00:22:23 -0000

At least part of this commentary wound up in
     Guidelines for Using IPv6 Transition Mechanisms during IPv6
     Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=49679 bytes)
     (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180)

I think Jari's view in that was that we needed to rein in the plethora of transition technologies, and "if one has to translate, can we please do so above the IP layer?" I added SIIT/NAT64, because I think there is market relevance including several deployments of various kinds; any mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic recommendation of RFC 6180 was:
  - first choice, deploy native IPv6
  - for scenarios in which IPv6 islands are connected across IPv4 space, use dslite (a tunneling design).
  - for scenarios in which IPv6 systems have to talk with IPv4 systems, translate. Please consider doing so above the IP layer.

I would argue that 464XLAT, MAP-E, and MAP-T are "ways that an ISP might use SIIT/NAT64 in its network", and are therefore not fundamental transition technologies as much as ISP services built using them.

I think I might also argue that the market has more or less followed that advice. Your spreadsheet seems to suggest that.

> On Jan 19, 2018, at 12:15 PM, Lee Howard <> wrote:
> The WG Chairs were discussing the various transition technologies at some length today.
> I mentioned a previous conversation in another forum that led to this list of networks and their mechanisms:
> (Corrections and additions encouraged, especially with links)
> Our impression was that of the 26+ transition mechanisms defined, only a few have any modern relevance (editorial comments are mine, not consensus positions):
> 6rd.   It may be that its light is waning, with early deployments moving to native IPv6, and no new deployments.
> DS-Lite.   Widely deployed, existing support among home gateway manufacturers.
> NAT64/464xlat.   Implies NAT64, SIIT, which may be used elsewhere. Handset CLATs. No home gateway CLAT yet.
> MAP-T.   Announced trials and lots of buzz, but no large-scale deployments, no home gateway support yet.
> MAP-E.   Some buzz, no announced trials or deployments, no home gateway support yet.
> Native dual-stack.   Still the gold standard, but doesn’t solve IPv4 address shortage.
> (Note that “yet” may change at any time).
> As a matter of discussion, do you agree?
> To guide our work, is there work we should do to document or deprecate any of these?
> Thanks,
> Lee