Re: [v6ops] discussion of transition technologies

Alexandre Petrescu <> Wed, 24 January 2018 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 45F88124217 for <>; Wed, 24 Jan 2018 05:30:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Voemr_Yxn1nk for <>; Wed, 24 Jan 2018 05:30:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15349124207 for <>; Wed, 24 Jan 2018 05:30:01 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w0ODU0V3006355 for <>; Wed, 24 Jan 2018 14:30:00 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 0801C204FF5 for <>; Wed, 24 Jan 2018 14:30:00 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id F1FF3204F7B for <>; Wed, 24 Jan 2018 14:29:59 +0100 (CET)
Received: from [] ([]) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w0ODTxtL017317 for <>; Wed, 24 Jan 2018 14:29:59 +0100
References: <> <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Wed, 24 Jan 2018 14:29:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
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: Wed, 24 Jan 2018 13:30:05 -0000

Le 23/01/2018 à 18:23, Lee Howard a écrit :
> On 1/23/18, 4:13 AM, "Mikael Abrahamsson" <> 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.

A similar description you make on 6rd can be made on GTP-U protocol 
transpoprting IPv6 user data on UDP/IPv4 cellular networks.

Cellular operator does have answers about why they continue using IPv4 
to transport IPv6 (instead of using IPv6 to transport IPv6.)

For my part, I think the compute power goes so cheap that they can 
easily add layers upon layers and SDN them as they evolve their network, 
instead of designing on a clean slate.  New protocol?  Just beam up in a 
new overlaid world.

For this to change, maybe the sysadmins will complain the management is 
too complex, or some security attacks will go without possibility to 
track the cause, or maybe a completely new operator wants to deploy a 
new network with software and hardware whose price is in the range of 
small investors.

When that happes, they will be happy if an Internet Draft describing GTP 
on both IPv4 and IPv6 existed.


> Lee
> _______________________________________________
> v6ops mailing list