Re: [v6ops] discussion of transition technologies

Fred Baker <fredbaker.ietf@gmail.com> Mon, 22 January 2018 20:06 UTC

Return-Path: <fredbaker.ietf@gmail.com>
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 3059712706D for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 12:06:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Rm9dqwjCuTgh for <v6ops@ietfa.amsl.com>; Mon, 22 Jan 2018 12:06:03 -0800 (PST)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD91F12AF6E for <v6ops@ietf.org>; Mon, 22 Jan 2018 12:05:57 -0800 (PST)
Received: by mail-pf0-x244.google.com with SMTP id m26so7914709pfj.11 for <v6ops@ietf.org>; Mon, 22 Jan 2018 12:05:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Y8RvQ3kIow2dNXnYHlJ5zRcDrdWsVUYcb5G6DFx97oo=; b=tN3NfTP+/hN9VlqIbdUmNnyno6uKaUWQB3+sKocUWeJG9gN8xTm4qKpLVPjrQbtuEg oFf9Xn0L44hihZbNMOiFPCOBRtMohoPV8m+YolHDD6Vp3PsmRq07vyU0GYeKIqMVih0v VEgQYfsoAj+t6M0sYoidzNcvBCTvPxVEkk1eRSGPkecIhb58VLPdzjm2a23Y9kQTOs/K +4WV6Jl4azXQNv+KEn7Xu0C+wiCXrLZOQUEbtDz2vzXI+7zflz6J5OGQDXu5ljpyds0Y /C51Z1kRgQL/UBHqVkwzE4X+RpQJ4fx203YdXQddfc/SXEeVYv1fTJnuEvKf32yUc9IS zdKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Y8RvQ3kIow2dNXnYHlJ5zRcDrdWsVUYcb5G6DFx97oo=; b=fnOeA/Z151Hx7aP+9OlwwSF8h5lIVbLk3fW9YWNfngjTxZuoe+0k2EO10z/csRdlbj /2usiCkW2u4VUNKKpBRy+hXPIDh0K7j0FcP+Vweqn4FxiXQgBG1nAyavELirskZdol00 mk03NckWemtJswMu1kTSf+yk4/JDfdZSpz5bnJthWjTq8DLwH/x3e8CKWKqASJXorBnR WOMp7psbG0qkSj28Cr0Uhw9Hws7VX8VFNv+I7JSr0Jm+6+Na9MLO7ArPgjBxg21LCnOt puyNyjWSmekMLEG0kwk9hhsSP8fKpcTRsNI5fH5VeHd5S7VYwTHjaAT7zLYHSECQxUeI oogQ==
X-Gm-Message-State: AKwxytdd5x0eyVUAuAfpgdEN91yX7IWTcgIx8ERtlnGrCmzZ4zMjBG7m YmK4XMdOmi10eG6g38ij7kpycsn7
X-Google-Smtp-Source: AH8x2252KY/6yAOkZNJjCGJWsFUDz9Zd0QTfWfBV3qaLR+w4+pkzCWQ92UgcCre54tjYKvITheLYTQ==
X-Received: by 10.98.218.24 with SMTP id c24mr8970931pfh.145.1516651557523; Mon, 22 Jan 2018 12:05:57 -0800 (PST)
Received: from [192.168.1.7] (ip184-189-218-77.sb.sd.cox.net. [184.189.218.77]) by smtp.gmail.com with ESMTPSA id n80sm2579299pfj.79.2018.01.22.12.05.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 12:05:56 -0800 (PST)
From: Fred Baker <fredbaker.ietf@gmail.com>
Message-Id: <70EABBF2-8572-4D6B-8C92-E1F3E247D527@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_D2F14560-CD78-4B68-B8D7-C484E94F9EC0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 22 Jan 2018 12:05:53 -0800
In-Reply-To: <D68BA9E1.96407%lee@asgard.org>
Cc: Ole Troan <otroan@employees.org>, Sander Steffann <sander@steffann.nl>, "v6ops@ietf.org WG" <v6ops@ietf.org>
To: Lee Howard <Lee@asgard.org>
References: <D687BC24.92CC1%lee@asgard.org> <A6995969-0C03-4261-92F4-331206825130@gmail.com> <D29099E6-510D-41DA-B998-6BF15E9FDE7F@gmail.com> <D68B9BCE.96312%lee@asgard.org> <A5D8E026-ADB1-487C-AC20-30CA478A7B89@employees.org> <D68BA9E1.96407%lee@asgard.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/WawtBtkRdVMXtDjNLMJFYmUCA-0>
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 20:06:05 -0000


On Jan 22, 2018, at 11:54 AM, Lee Howard <Lee@asgard.org> wrote:
> On 1/22/18, 2:20 PM, "Ole Troan" <otroan@employees.org> wrote:
>>>>> 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.
>> 
>> Apart from giving millions of users IPv6 access?
> 
> Why would anyone want to do that?
> 
> That’s a bit of a snarky question, but it’s a real one. Is there any
> real-world problem for which 6rd is the best answer?

I think the problem space I'm familiar with is stated in my previous note in this thread (scroll up). Imagine that you are a network operator (ISP or enterprise) and have some IPv4-dependent system (or set of systems) that you haven't replaced yet (or can't replace) that you need to jump over to create an IPv6 deployment. That might be as simple as - what I understand to have been Free's business case until recently - you have an IPv4 network and want to rapidly deploy IPv6. Or, the case I'm told another company had, that its DSL infrastructure was IPv4-only and 6rd allowed it to factor that out of the discussion until they could fix it (now, I'm told, fixed). "IPv6 islands connected by IPv4 infrastructure", which might be continents and peninsulas, who knows.

Now, to my mind and I think yours, the best answer to "I want to deploy IPv6" is "so do so". Where it becomes an issue is "but that costs money for some reason". 6rd might be a temporary measure to provide the service until the money was no longer an issue.

> “I can’t update my network to support IPv6, but there are IPv6-only hosts
> that my users need to be able to reach” is the scenario 6rd addresses. Is
> that an actual case? The case “My ISP hasn’t updated to support IPv6, but
> there are IPv6-only hosts I need to reach” is solved with a tunnel broker.
> 
> I don’t deny that it is deployed at scale. I’m asking whether there are
> any new deployments, recent or contemplated, and what path on a decision
> tree would lead one to decide “6rd.”
> 
> Lee
> 
> 
>