IETF Logo Mail Archive

Re: [v6ops] Turning on IPv6 Routers

Nick Hilliard <nick@foobar.org> Thu, 20 July 2017 15:25 UTC

Return-Path: <nick@foobar.org>
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 E9A8E131CE6; Thu, 20 Jul 2017 08:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 TfhtlHfVTN5x; Thu, 20 Jul 2017 08:25:10 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F1C131C43; Thu, 20 Jul 2017 08:25:09 -0700 (PDT)
X-Envelope-To: ipv6@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v6KFP5Yx088569 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jul 2017 16:25:06 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <5970CB51.3090806@foobar.org>
Date: Thu, 20 Jul 2017 16:25:05 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.16 (Macintosh/20170718)
MIME-Version: 1.0
To: Fred Baker <fredbaker.ietf@gmail.com>
CC: draft-ietf-6man-rfc6434-bis@ietf.org, IPv6 Ops WG <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com>
In-Reply-To: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/n-IxoPOU-2t9X5LMXfOi2hkKrXQ>
Subject: Re: [v6ops] Turning on IPv6 Routers
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 20 Jul 2017 15:25:12 -0000

Fred Baker wrote:
> "If IPv4 router operation is enabled by default, enable IPv6 router
> operation by default."

this is undoubtedly well-intentioned, and the idealist bit in me
sympathises with the principal.  However with my enable hat on, a
recommendation like this isn't going to fix any problem associated with
ipv6 adoption.

The problems with ipv6 adoption revolve entirely around cost/benefit.
Pressing problems still include things that should have been resolved
years ago, e.g. vendors charging extra for ipv6 support (today's
bugbear: provisioning system vendors, please note that charging extra
for basic ipv6 functionality is destructive in the long term and
corrosive for your customer relationships)

As a separate issue, from an operational point of view, implicit
enabling of functionality in one area when it's explicitly enabled in
another is something that needs to be handled carefully because
otherwise you can end up violating the principal of least astonishment.

Nick

v2.23.0 | Report a Bug | By Email