Re: [v6ops] discussion of transition technologies

Fred Baker <> Sun, 21 January 2018 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C4BE12D77C for <>; Sun, 21 Jan 2018 11:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BZdN_-LPio5v for <>; Sun, 21 Jan 2018 11:28:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F659127023 for <>; Sun, 21 Jan 2018 11:28:14 -0800 (PST)
Received: by with SMTP id u1so5407800pgr.0 for <>; Sun, 21 Jan 2018 11:28:14 -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=1f4Iq24jqVA2YFfdrwbLVV5wCvMeOmgUHJwQK4Y0Bts=; b=ax5mVhUlpQ3ChEXbawM3eACWaLLtgGSmRgqJA5blE5GHSqXmQsxdX1Hsy7UlEqqs0o GvVng1wCrYbEyhObbBR+JCoLtzWD1sW71dNPDRXU3tLUV77miCL0bnMIOlhl4h0ejeQH 1rIgYq88mkBiQtKfK5UozHE3m3bdx4KfzSZAsze87kfAdssOwBlGbdMfKfhbOkyTV1DK jXjtsvqPdbcyf6LHjk2QpFPypU3Wu5+wBObJTC9Og1HgnUVbWSIJdZjzE0uLtVlmQjF9 fgM6y6klykw8RDFOZjknsW7NehNIxSjCJH0IgOCuodzqBf4lVuhyevW8W3vCzs1HmsGI CtEQ==
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=1f4Iq24jqVA2YFfdrwbLVV5wCvMeOmgUHJwQK4Y0Bts=; b=rkM5AXlpXa5CtEChOxM8i4dyuDvtBfAci5jH4GkvDUe49ElSXpSoDN/DjfMSL/K3bl KF0BtALkf77089xhnNFp8LMsdR42AuysWWp9IaNIDAqABiaMrsnQJZO+6vGQeT2Jia85 TuVv7CVsiMsQOPmHkDFu7obvUecbbcpOj8kQFBgZ8A6ail8Wn4VofLYk2mUrXvWCRdOn isZz3jHKkebMwJuB9+7Rt1mZ2oXGY3JJ4tDsIIDFrPXRc/Vr4jMavi9Q6HhA08xhxssi numqlfpDjQxZ0FuQnkO76hi/O5yML41R5+iMMqcBP0yAMj+oSJQsztfncY60Jajq2rTR ASyg==
X-Gm-Message-State: AKwxyteUoUlVotQT/00/dhnb5d7ZRmqbl/9neUz57M0a2ujngmrrwBKB 3RdfB8bjhlAdw2dc+KbCNwzAkd6c
X-Google-Smtp-Source: AH8x227D/2jxcF8K0iCzC61iKL97q7e5vSG3hGU3zZs6tEeGjkO4srLV3DI5iqdZSBxap9lIE6HftQ==
X-Received: by with SMTP id o190mr1742584pga.238.1516562893465; Sun, 21 Jan 2018 11:28:13 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id o1sm28309124pfa.101.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jan 2018 11:28:12 -0800 (PST)
From: Fred Baker <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_10F2EE59-37D8-4C9F-B183-C2B8AD193189"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Sun, 21 Jan 2018 11:28:09 -0800
In-Reply-To: <>
Cc: " WG" <>, Lee Howard <>
To: Sander Steffann <>
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: Sun, 21 Jan 2018 19:28:23 -0000

Restated. Close?

> On Jan 19, 2018, at 4:22 PM, Fred Baker <> wrote:
> 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 IPv4 islands are connected across IPv6 space, use dslite (a tunneling design).
  - for scenarios in which IPv6 islands are connected across IPv4 space, use 6rd (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 "services in which 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.

The interesting thing is that 6rd, which is a way of appearing to have an IPv6 network without actually having one, is not what one might call "prevalent". It has in fact been used for *transition*, in places like Free - which used to connect IPv6 customers using 6rd and (I understand) has recently announced native IPv6 deployment. The places I know that have used it used it for a while and then have gone native.

Would you agree with that?

Side comment: I wrote the above and then read it back. The common meaning of the phrase "go native" is not what I meant (it's derogatory), but humorous in context.

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