Re: [v6ops] discussion of transition technologies

Lee Howard <lee@asgard.org> Mon, 22 January 2018 19:00 UTC

Return-Path: <lee@asgard.org>
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 595B3126D45 for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 11:00:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX5dhReT86JS for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 11:00:52 -0800 (PST)
Received: from atl4mhob16.registeredsite.com (atl4mhob16.registeredsite.com [209.17.115.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05064126D73 for <v6ops@ietf.org>; Mon, 22 Jan 2018 11:00:51 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id w0MJ0n9O045137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <v6ops@ietf.org>; Mon, 22 Jan 2018 14:00:49 -0500
Received: (qmail 25591 invoked by uid 0); 22 Jan 2018 19:00:49 -0000
X-TCPREMOTEIP: 174.64.33.182
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.2.101?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 22 Jan 2018 19:00:48 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Mon, 22 Jan 2018 14:00:42 -0500
From: Lee Howard <lee@asgard.org>
To: Fred Baker <fredbaker.ietf@gmail.com>, Sander Steffann <sander@steffann.nl>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
Message-ID: <D68B9BCE.96312%lee@asgard.org>
Thread-Topic: [v6ops] discussion of transition technologies
References: <D687BC24.92CC1%lee@asgard.org> <A6995969-0C03-4261-92F4-331206825130@gmail.com> <D29099E6-510D-41DA-B998-6BF15E9FDE7F@gmail.com>
In-Reply-To: <D29099E6-510D-41DA-B998-6BF15E9FDE7F@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/v8wDXxHjmBBHb3sIDH__PRWvPv4>
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 19:00:54 -0000


On 1/21/18, 2:28 PM, "Fred Baker" <fredbaker.ietf@gmail.com> wrote:

>Restated. Close?
>
>> On Jan 19, 2018, at 4:22 PM, Fred Baker <fredbaker.ietf@gmail.com>
>>wrote:
>> 
>> At least part of this commentary wound up in
>>https://tools.ietf.org/html/rfc6180
>>     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).

You would argue that 464xlat, MAP-E, and MAP-T are simply implementations
of SIIT/NAT64 (which you do, below), but it seems to me that they are also
used in these scenarios. In some cases the “island” is but a single
application on a mobile phone.

For large networks, like access ISPs, mobile networks, and maybe campus
networks, the advice might be finer-grained:
- for scenarios in which IPv4 islands (e.g., households, a mobile phone,
or other stub network), consider:
 — If you need home gateway support right now, use DS-Lite
 — If you are using CGN anyway (such as mobile networks), consider
464xlat, which allows native IPv6 end to end when possible, native IPv6
end-to-translation-edge when IPv4 is needed to reach the other end, and
CLAT on the device or IPv4 edge when the local application or device
requires it.
 — If you can pressure or wait for home gateway vendors for MAP support
and would prefer stateless BRs (probably more scalable/cheaper than
stateful DS-Lite AFTR), use MAP. (One more decision branch between MAP-T
and MAP-E, but they’re pretty close).
 

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

I would; that is my perception. MHO is that 6rd has had its day, and while
I don’t think it needs to be deprecated, I haven’t heard any scenarios in
the past several years where it solves an actual problem.


Lee