Re: [v6ops] discussion of transition technologies

Lee Howard <lee@asgard.org> Tue, 23 January 2018 17:23 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 367B0127137 for <v6ops@ietfa.amsl.com>; Tue, 23 Jan 2018 09:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 FnES5ueqOMuw for <v6ops@ietfa.amsl.com>; Tue, 23 Jan 2018 09:23:18 -0800 (PST)
Received: from atl4mhob22.registeredsite.com (atl4mhob22.registeredsite.com [209.17.115.116]) (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 49BAD12706D for <v6ops@ietf.org>; Tue, 23 Jan 2018 09:23:18 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob22.registeredsite.com (8.14.4/8.14.4) with ESMTP id w0NHNFDn103427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <v6ops@ietf.org>; Tue, 23 Jan 2018 12:23:15 -0500
Received: (qmail 23569 invoked by uid 0); 23 Jan 2018 17:23:15 -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; 23 Jan 2018 17:23:14 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Tue, 23 Jan 2018 12:23:11 -0500
From: Lee Howard <lee@asgard.org>
To: Mikael Abrahamsson <swmike@swm.pp.se>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>
Message-ID: <D68CD7C8.966A0%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> <D68B9BCE.96312%lee@asgard.org> <A5D8E026-ADB1-487C-AC20-30CA478A7B89@employees.org> <D68BA9E1.96407%lee@asgard.org> <alpine.DEB.2.20.1801231001340.8884@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.20.1801231001340.8884@uplift.swm.pp.se>
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/2whlC5gk3Av5f17P2vkbPW9Lp4o>
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: Tue, 23 Jan 2018 17:23:20 -0000


On 1/23/18, 4:13 AM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:

>On Mon, 22 Jan 2018, Lee Howard wrote:
>
>> 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 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.”
>
>I know people who seriously are still considering this, because they're
>using old access tech which will never gain native IPv6 capability. So
>it's "6RD" or "no IPv6 at all for the lifetime of the platform".
>
>Like "we have this ethernet-over-DSL DSLAM from 2006 that seems to still
>work, aggregates a bunch of customers, everybody is in the same VLAN, and
>the vendor has EOLed this platform in 2012, we're seeing declining
>customer base but it's non-zero, and we need IPv6 SAVI functions to
>deploy 
>IPv6 securely". Or "we buy bitstream access over ethernet to a bunch of
>customers, but the bitstream access provider is IPv4 only because
><reasons 
>I just described earlier, and add
>bitstream-provider-doesn't-see-business-need-to-deply-Ipv6>."
>
>I have talked to multiple people who have pretty compelling business
>reasons not to touch old access platforms, so it's 6RD or nothing. At
>least I haven't been able to come up with something better.

That’s a great example, thank you.

That’s also why I would describe 6rd as declining: its primary use is for
bypassing ISP edge equipment that’s 12 years old and EOL. As time passes,
the number of users behind equipment like that (where “12” continues
incrementing) will continue to decline. If my network was gradually
transitioning from old DSL or DOCSIS1.x, I might suggest enabling IPv6 on
the newer edge boxes and not bothering with the old ones. Or even doing
stateful NAT46 for the very few flows that needed to reach something on
IPv6.

But that’s just me, and I appreciate anyone who is trying to push IPv6 to
those users on older technology.

Lee

>