Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC]

Owen DeLong <> Thu, 08 August 2013 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A4ED1F0D38 for <>; Thu, 8 Aug 2013 10:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GPU8KJXkkdT7 for <>; Thu, 8 Aug 2013 10:56:10 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 8C1B921F9E99 for <>; Thu, 8 Aug 2013 10:56:08 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.2/8.14.1) with ESMTP id r78HsouP010759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 8 Aug 2013 10:54:51 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 r78HsouP010759
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=mail; t=1375984492; bh=rE46qutbRjxWD45uHi/m86AjYOE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NaMxMxVfcE61fcexnwOWCA24r5+yCmwbQ+qTZ1jY5E7fBCXMJUlt8PH9mEPkM3Gsl BLVIZlf+OrpvJV7//D/sd1PIMlpmkOyNJyLFDbMU+q+iJZtjXRW+ebTnQOajqj/OYC AZiVqtDvW/ji6aspDdGhlFB8Mq5tViSp9NGq0ZZo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Thu, 8 Aug 2013 10:54:53 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <20130808170533.GI65295@Space.Net> <>
To: Ray Hunter <>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 ( []); Thu, 08 Aug 2013 10:54:52 -0700 (PDT)
Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Aug 2013 17:56:11 -0000

On Aug 8, 2013, at 10:28 AM, Ray Hunter <> wrote:

>> Gert Doering <>
>> 8 August 2013 19:05
>> Hi,
>> To get rid of dual-stack operations, while still being able to benefit
>> from the large address space of IPv6 inside the enterprise?
> Who has an IPv4 address shortage *inside* the enterprise?
> And what are these benefits *inside* the enterprise?
> LAN switches are written off over at least 10 years in the book keeping.

Arguably, anyone using RFC-1918 space is suffering from an address
shortage inside their enterprise. Given the clear and obvious benefits
of eliminating NAT and having globally unique addresses for every
system which communicates with the internet, I wonder how you can
ask such a question with a straight face.

A 10 year depreciation on switches is absurd. Most enterprises I know of
use either a 3-year or 5-year depreciation schedule for network equipment
such as LAN switches and many end up retiring them faster than they

> AFAICS the only thing most large enterprises are worried about right now
> is the border, and Internet and outward facing systems (and rightly so).
> They'll be able to run *private* IPv4 networks over MPLS or GRE or
> something else for many many years to come, with all of their important
> partners, and there'll be plenty of vendors wiling to support them on
> old kit at cut prices.

I think you are right about what most enterprises are worried about right
now (if they are even paying attention at all). However, enterprises are
not exactly known for paying attention to anything more than 3 months
away from now, so I don't think that's a great yardstick.

It will be interesting to see how this plays out. I think that the cost of
continuing to support IPv4 in the face of an ever-increasing proportion
of the internet not being IPv4 capable will lead enterprises to abandon
IPv4 for the most part much faster than is currently anticipated.

We saw this with the IPX->IP transition. Everyone thought we'd be
running IPX everywhere for 20-30 years, yet once IP gained critical
mass in the enterprise, IPX all but disappeared in less than 5 years.

> If SNA or DECnet IV is any transition model to go by, it took about 20
> years for them to die inside most enterprises, whilst they generally
> died much quicker at the border. It went something like: native SNA or
> native routed DECnet IV on original vendor equipment -> multi-protocol
> routers -> tunnelled SNA or DECnet IV -> islands with gateways ->
> islands -> switch off.

I think IPv4 will get to the islands with gateways much faster than DECNET
or SNA. I think that the IPX (and/or Appletalk) transition(s) to IP are a much
more informative model.

SNA, especially, was a very different networking model from IP and IBM
(as well as HDS and other IBM clones) were very very slow to support
TCP/IP other than through gateways. They still depended on SNA for
the vast majority of their peripherals, terminals, etc. It wasn't until most
3270/5250 terminals were replaced by PCs that the real move away
from SNA started in earnest. At that point, SNA mostly disappeared fairly
quickly. Much less than 20 years.

IPX and Appletalk, OTOH, provided very similar overall services on a very
similar conceptual model to IP. As a result, that transition was quite a bit
easier and the enterprise migration consequently happened quite rapidly.

I'm sure you can still point to islands of IPX or Appletalk running here and
there in a few enterprises, but what was once the flagship product of a
major player in the industry (IPX / Novelle) is now basically relegated
to history and the company is an also-ran at best.

> The final straw was making end users pay pro-rata for the support costs
> of the shrinking infra. IMVHO Whilst there's still economies of scale,
> there's simply no business case *inside* the enterprise except for
> opportunistic switch on at standard scheduled lifecycle renewal. I've
> been through this loop myself. But then again, why should the IETF care
> what happens in that case if the border interface is clean and IPv6 only?

The IETF probably shouldn't really care. However, this is  an informational
RFC intended to help enterprises get from A to B in an orderly manner. As
such, I think it is appropriate to document that process.

Further, I think you will see the escalating cost of IPv4 at the eyeball ISP as
the first driving factor for deprecating IPv4 and I think that will happen quite
a bit faster than most people expect.

As a general rule, once CGN starts to be widely deployed and ISPs start
having to charge extra to cover the escalating costs of CGN (especially
WRT the CALEA implications), you'll see consumers choosing IPv6 only
over paying extra for even more degraded IPv4 service.