IETF Logo Mail Archive

Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 29 March 2013 13:38 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6A621F85B3; Fri, 29 Mar 2013 06:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.574
X-Spam-Level:
X-Spam-Status: No, score=-100.574 tagged_above=-999 required=5 tests=[AWL=1.117, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 W8zxYdZBASGU; Fri, 29 Mar 2013 06:38:02 -0700 (PDT)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFE721F941C; Fri, 29 Mar 2013 06:38:00 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id f12so429915wgh.10 for <multiple recipients>; Fri, 29 Mar 2013 06:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IBWIbj94Bh1mSMYk1Z7F8vRD8Ll/8vDqjua0DIlOm1E=; b=pjwwVp9SmmxXSYG333MFwLP+YYn+zb9hOPB/sHYeLpzPpdlWBzHK6+bOWX7O7RWUAt Uv4NmLCuSSRE44+J6VK4VpX2DCC1iYcFDGtcsNxHgstWXmX8v9xfllB9cM1TNbvRI6/O CbOTlQ5GHyG2VcyD74yu7spR+QCFQ+EuN15L5X0nPsP8dce3itfEGCJdsHfwrG8p4ncq 4A7rBKY60B19lLUXdIuOGvYi1bIeDZbebqkwbq3Pox/twYUyq1FPvZdvDGwhAfQ44Slg 0xwD0FSNRpl+bZE6ZppDxnN6U/yXmP7eHPlU58me03FpF7yK/Aw0zoeL/OTO35l4lmZ+ 3cXQ==
X-Received: by 10.180.92.229 with SMTP id cp5mr22107504wib.20.1364564279881; Fri, 29 Mar 2013 06:37:59 -0700 (PDT)
Received: from [192.168.1.65] (host-2-101-189-148.as13285.net. [2.101.189.148]) by mx.google.com with ESMTPS id h10sm3953154wic.8.2013.03.29.06.37.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Mar 2013 06:37:58 -0700 (PDT)
Message-ID: <51559943.1010703@gmail.com>
Date: Fri, 29 Mar 2013 13:38:11 +0000
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: ietf@ietf.org
References: <20130329130326.13012.1402.idtracker@ietfa.amsl.com>
In-Reply-To: <20130329130326.13012.1402.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: opsec@ietf.org
Subject: Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2013 13:38:02 -0000

Hi,

My minimal request for this draft is for my name to be removed from
the Acknowledgements, as I do not think that my comments have been
acted on.

In fact, I think that in its current state, this document is harmful
to IPv6 deployment. It in effect encourage sites to fence themselves
into an IPv4-only world. Particularly, it explicitly suggests a
default/deny approach to IPv6-in-IPv4 tunnels, which would prevent
the typical "baby steps" first approach to IPv6 deployment.

I would like to see the document convey a positive message, suggesting
that an IPv4 site first decides which IPv6 deployment mechanism it
will use, and then configures security appropriately (to allow that
mechanism and block all others). This wouldn't affect the technical
recommendations much if at all.

A specific aspect of this is that if a site provides one well-managed
6in4 tunnel mechanism, all tunneled IPv6 packets will pass through
well-defined points where security mechanisms may be applied.

We shouldn't imply that not having an IPv6 plan and blocking all IPv6
by default is a sound strategy.

Regards
   Brian

v2.23.0 | Report a Bug | By Email