Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Fred Baker <fred@cisco.com> Sun, 17 April 2011 20:08 UTC

Return-Path: <fred@cisco.com>
X-Original-To: v6ops@ietfc.amsl.com
Delivered-To: v6ops@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F1475E0724 for <v6ops@ietfc.amsl.com>; Sun, 17 Apr 2011 13:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.33
X-Spam-Level:
X-Spam-Status: No, score=-110.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5pshU1I6fEQ for <v6ops@ietfc.amsl.com>; Sun, 17 Apr 2011 13:08:11 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 06FCEE0681 for <v6ops@ietf.org>; Sun, 17 Apr 2011 13:08:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2401; q=dns/txt; s=iport; t=1303070891; x=1304280491; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=2srYb9/IiJmTwr7GeZ+t5Gm3cAk64b7mKXYIyhzI1zE=; b=KGTPWNVsKqZTMOoc24Q08BdEko3evtuU8MrIXtc4Fd7hgJgE0T0uVB7g WUN4X2o92/s5EvkNvE9KgEJBkfrVQTRewOsuswdMfUu2/sc5cC1KibncG D0/fGxs8Ea1cge6rqBBHKHWbkVdi6ypUSAEyHF+sbBrH9iBW/nivwfgdb Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtgGAMNHq02rRDoJ/2dsb2JhbACYG41Bd4hvniibGYVxBIViiCGDdQ
X-IronPort-AV: E=Sophos;i="4.64,228,1301875200"; d="scan'208";a="339319087"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 17 Apr 2011 20:08:10 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3HK858K018370; Sun, 17 Apr 2011 20:08:10 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 17 Apr 2011 13:08:10 -0700
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 17 Apr 2011 13:08:10 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <C9D101B9.39105%jordi.palet@consulintel.es>
Date: Sun, 17 Apr 2011 13:07:51 -0700
Message-Id: <A2AD655B-D0DD-41EE-9C00-815631398C08@cisco.com>
References: <C9D101B9.39105%jordi.palet@consulintel.es>
To: jordi.palet@consulintel.es
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org, Ron Bonica <ron@bonica.org>
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic 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: Sun, 17 Apr 2011 20:08:12 -0000

On Apr 17, 2011, at 11:47 AM, JORDI PALET MARTINEZ wrote:

> Otherwise, we need to follow the same approach for 6over4, ISATAP, Teredo
> (I mean deprecating them), and for many many many other transition mechs.

</chair>

If by 6over4 you mean explicit tunnels, I think they are already something someone does consciously.

From my perspective, so-called "transition mechanisms" are poorly named; they are in fact "coexistence" mechanisms (mechanisms that help IPv6 be an equal player in an otherwise-IPv4 network) or "prototyping" mechanisms that enable us to gain IPv6 experience in an otherwise IPv4 network.

Again from my perspective, we have entered a new phase. In this new phase, IPv6 and IPv4 are essentially equal players, and the objective is to develop and harden that deployment. There will be a turndown phase for IPv4 at some point in the future; that will be driven by business requirements. People with old equipment will continue to run it, which will mean that IPv4-only printers will continue to be used on people's desks and so on. But at the point that the vast majority of people, equipment, and applications are just as happy with either IPv4 or IPv6, folks will wonder why they need both and start turning IPv4 off. Solutions like ds-lite and 4rd are best thought of as in support of that; I can run IPv4 as an overlay on an otherwise IPv6-only network at some point.

But in this phase, to my way of thinking, the objective is to harden and stabilize the IPv6 infrastructure. Solutions that are primarily useful for prototyping at best have a limited role in that; anything that depends on IPv4 should either be operated by the network administration for a specific purpose, such as for example using 6rd as a way of working around equipment that is difficult or expensive to upgrade at the time the rest of the network is. If you heard Geoff Huston's talk at IETF-80, yes, there's a lot of 6to4 and Teredo in the network; he finds a lot of each in his dark nets, demonstrating that people that use it are often experiencing a degraded IPv6 service as a result of using it. That doesn't sound like "hardening and stabilizing".

I would agree with the point that things people are doing should be things they consciously decide to do, and can easily decide to not do.