IETF Logo Mail Archive

Re: [v6ops] Operational Consensus on deployment

"William F. Maton Sotomayor" <wmaton@ottix.net> Tue, 05 August 2014 12:56 UTC

Return-Path: <wmaton@ottix.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108121ABB17 for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 05:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 jClyRUJ_T65p for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 05:56:32 -0700 (PDT)
Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) (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 375AC1A8BAF for <v6ops@ietf.org>; Tue, 5 Aug 2014 05:56:32 -0700 (PDT)
Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.9/8.14.9) with ESMTP id s75CuNbG027940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Aug 2014 08:56:24 -0400
Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.9/8.14.6/Submit) with ESMTP id s75CuM0d027935; Tue, 5 Aug 2014 08:56:22 -0400
Date: Tue, 05 Aug 2014 08:56:22 -0400
From: "William F. Maton Sotomayor" <wmaton@ottix.net>
To: Tore Anderson <tore@fud.no>
In-Reply-To: <53E06AC9.9010908@fud.no>
Message-ID: <alpine.DEB.2.03.1408050854200.19219@iskra.ottix.net>
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <DE860EBC-171E-46E7-A3B6-5E8B79A453CC@cisco.com> <53DFEC6C.3010707@gmail.com> <CAD6AjGRUWxT5XiNxMi_S5VgYtGMLb_FVHXN-ZfGpcY=geix15g@mail.gmail.com> <53E06AC9.9010908@fud.no>
User-Agent: Alpine 2.03 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jr2M3U4xfhw33YLvleVMOgscbwg
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Operational Consensus on deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 05 Aug 2014 12:56:34 -0000

On Tue, 5 Aug 2014, Tore Anderson wrote:

> * Brian E Carpenter
>
>>> (In parenthesis, I've never seen sunsetting IPv4 as a real problem.
>>> One day somebody will notice that there are no more IPv4 packets. But
>>> that is many years in the future.)
>
> The thing is, if you've built your infrastructure on IPv4, removing it
> is going to be a royal pain in the arse. Even if all the IPv4 users have
> left the public internet, if your application server speaks to your
> database server over IPv4, and the database server speaks to the iSCSI
> array over IPv4, and so on and so on, then you're simply not in a
> position to easily shut IPv4 off.

Worse still is all the gear to workaround NAT, so it isn't just the usual 
suspects of desktops vs servers vs appilcations, but also the 
point-to-point setups (video conferecing comes to mind) I have encountered 
that require going around NATs.

(There is something to be said about a net gain in maintenace overhead in 
elminating some of that, but there's also the effort to remove it and 
test, etc.)

wfms

v2.23.0 | Report a Bug | By Email