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

Owen DeLong <owen@delong.com> Fri, 09 August 2013 19:23 UTC

Return-Path: <owen@delong.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 BAE9511E81BD for <v6ops@ietfa.amsl.com>; Fri, 9 Aug 2013 12:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDSe5OEPWvz0 for <v6ops@ietfa.amsl.com>; Fri, 9 Aug 2013 12:23:01 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4571621F9D2C for <v6ops@ietf.org>; Fri, 9 Aug 2013 12:16:33 -0700 (PDT)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r79JBHjc019115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2013 12:11:17 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r79JBHjc019115
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376075479; bh=5IDreec5ttNCw7KGsVj96C/0+a0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=g0xfeJmDkz1fJCryV5y42M1wlurJ84OuS0X+8KGc3FLZL8gs3r6OMr5ko0fRObP24 gBLf5g6V4g+hVgwDrCk57L/xcEvH8K25zbsohs2Aw4PKhgPeCuL4gUAyPtOX1gfOIr yWWIBY8VMctPXBLW26UDSQL2WlQulqEl76NQ6GJo=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <5204024F.8080703@globis.net>
Date: Fri, 9 Aug 2013 12:11:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FEC6F410-9BAB-4C0C-8004-C959177CA4C1@delong.com>
References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <CAD6AjGTGL9JVK6egOAVXhMFv77L0b=9eVjKAauwNzLnaM=Mcyw@mail.gmail.com> <52031D69.3070604@gmail.com> <CAD6AjGTAJVvmG_byRMW_F2g+WDBvdRLop_oLshgwbUsfBjRzbA@mail.gmail.com> <CAKC-DJh1q+sJB00yo7HsFifWb=42teg_ga4CjRQVVecU1emcDA@mail.gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net> <562895EB-247C-4FBE-9BA3-34F9C9408853@delong.com> <5204024F.8080703@globis.net>
To: Ray Hunter <v6ops@globis.net>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 09 Aug 2013 12:11:19 -0700 (PDT)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 09 Aug 2013 19:23:02 -0000

On Aug 8, 2013, at 13:40 , Ray Hunter <v6ops@globis.net> wrote:

>> Owen DeLong <mailto:owen@delong.com>
>> 8 August 2013 19:54
>> On Aug 8, 2013, at 10:28 AM, Ray Hunter <v6ops@globis.net> wrote:
>> 
>>>> Gert Doering <mailto:gert@space.net>
>>>> 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.
> But that pain has been solved 5 years ago in most places I work. There's
> no burning platform.
> 
> How would introducing a new technology like NAT64/DNS64 make things
> better in places where it hasn't been solved?
> [the original point of the thread] it's yet another NAT box.

The pain hasn't been solved, we've decided to live with it.

However, that aside, I'm not arguing for NAT64/DNS64. I'm saying that
eliminating NAT is obviously beneficial. NAT64 is jut another broken form
of NAT.

NAT is inherently problematic and breaks things. It causes pain.

Yes, I'm familiar with your argument of "if it doesn't work through NAT, then
I don't want it to work." I suppose that's one way to view the world, but I
would argue it's akin to insisting that your vehicle run on fossil fuels, even
if there were a viable truly cleaner sustainable alternative.

NAT is a form of toxic pollutant on the internet, whether the polluters see
that or not.

>> 
>> 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
>> depreciate.
>> 
>>> 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.
>> 
>> Owen
>> 
>> 
> Actually I think your reasoning and reference to the IPX and Appletalk
> phase out would suggest it's easier to make a bold call: move to IPv6
> ASAP for critical systems via dual stack, and for the rest you draw a
> box around it and call it legacy and run it on IPv4 until it dies a
> natural death.

That's certainly one approach. In my experience, that's not what happened
with most enterprises. Most enterprises ran both IPX and IP clients on their
workstations for a few years until they could kill off all the servers that were
inside those "legacy" boxes you drew.

> IMHO Going half way with NAT64/DNS64 just prolongs the pain and locks
> you into a transition technology that is expensive and difficult to
> operate for the life cycle of that box, and which has to remain in place
> until the last app is migrated or switched off.

Nothing I said was intended to support or encourage NAT64. It's simply
awful. It might be a better alternative than CGN or certain other things
in SOME very limited circumstances, but NAT64 is usually just a worse
form of NAT than traditional NAT.

> I've been in a fair number projects where you sometimes just have to
> dare to cut the cord whilst maintaining a process to find out what has
> broken. So one valid IPv6 only migration strategy might be: "If it's
> important, they'll migrate before a flag day date. Otherwise they get
> cut off."

It might be, but it's one that most IT managers will be very uneasy about
implementing (at least in my experience).

Owen