Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).

Lee Howard <> Thu, 29 December 2016 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 468391295C4 for <>; Thu, 29 Dec 2016 07:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RKjvXhGeLgpb for <>; Thu, 29 Dec 2016 07:28:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B023B1295D7 for <>; Thu, 29 Dec 2016 07:28:28 -0800 (PST)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id uBTFSQop020723 for <>; Thu, 29 Dec 2016 10:28:26 -0500
Received: (qmail 14167 invoked by uid 0); 29 Dec 2016 15:28:26 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 29 Dec 2016 15:28:24 -0000
User-Agent: Microsoft-MacOutlook/
Date: Thu, 29 Dec 2016 10:28:19 -0500
Subject: Re: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).
From: Lee Howard <>
To: Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?= <>, John C Klensin <>
Message-ID: <>
Thread-Topic: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).
References: <> <> <> <049f01d2613f$c5431ef0$4fc95cd0$> <> <> <> <> <5FBCC938E3BF3F24CD0B9C42@PSB> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Archived-At: <>
Cc:, IETF Rinse Repeat <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Dec 2016 15:28:30 -0000

On 12/29/16, 4:23 AM, "ietf on behalf of Patrik Fältström"
< on behalf of> wrote:

>On 29 Dec 2016, at 10:03, John C Klensin wrote:
>> I don't particularly dislike IPv6, I just think we've failed to
>> pay enough attention to incentives and barriers.  I wish it were
>> otherwise, really I do.

Lessons learned, and captured in draft-iab-protocol-transitions-04

>I completely agree with this. But I also see access providers and
>enterprises that regardless of how they have built their networks today
>do run out of IPv4 space. And when they have run out they only have a few
>1. Add another layer of NAT
>2. Buy IPv4 addresses
>3. Start running IPv6

These are not alternatives, but complementary elements to an overall

Running IPv6 doesn¹t mean you don¹t need to buy addresses or deploy NAT.
It may reduce the amount your NAT is used (esepcially useful for those
applications that don¹t play well with NAT). It might reduce the number of
addresses you need to buy (if your addresses are being used on the outside
of your NAT).
The value of running IPv6 increases over time.

>No, we are obviously not ready with [3] yet,

I don¹t understand this statement, since thousands of access providers and
enterprises are running IPv6. As reported by Mr. Vyncke, users in 20
nations use IPv6 10% of the time to get to IPv6-enabled sites; that¹s only
a fraction of the number of users who have IPv6 capability. Most people in
Belgium use IPv6, and about 1/3 of users in four other countries use IPv6.

I don¹t see how this is a failure, or how IPv6 isn¹t ready.

>And that is why I still see [3] coming, but not yet. We are getting
>closer every year though because the number of things that do need IPv4
>addresses increase. And even a NAT box do not decrease the number of IPv4
>addresses much due to the number of concurrent flows from clients.

Things. The only things that don¹t support IPv6 are Things.
Okay, there are a couple of apps (Skype) and sites (Amazon, Microsoft,
Twitter), though cloud and CDNs are coming along now. I¹ve been predicting
2018 as The Tipping Year for IPv6 for about five years, and I¹m standing
by it. 

>Because of this, I still think we must make [3] easier, because when
>people really need IPv6 we must be done.

In what ways is it difficult to ³Start running IPv6²?
We even have guidance on this in RFC7381 ³Enterprise IPv6 deployment


>   Patrik