[v6ops] Error in draft-ietf-v6ops-ra-guard-implementation-07
"C. M. Heard" <heard@pobox.com> Thu, 30 January 2014 17:15 UTC
Return-Path: <heard@pobox.com>
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 034D71A0456 for <v6ops@ietfa.amsl.com>; Thu, 30 Jan 2014 09:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level:
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_HDRS_LCASE=0.01] autolearn=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 08J4EcPWxcQ4 for <v6ops@ietfa.amsl.com>; Thu, 30 Jan 2014 09:15:02 -0800 (PST)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FA11A044A for <v6ops@ietf.org>; Thu, 30 Jan 2014 09:15:02 -0800 (PST)
Received: (qmail 10795 invoked from network); 30 Jan 2014 09:14:58 -0800
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jan 2014 09:14:58 -0800
Date: Thu, 30 Jan 2014 09:14:58 -0800
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: V6OPS <v6ops@ietf.org>
Message-ID: <Pine.LNX.4.64.1401300857260.25041@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: Fernando Gont <fgont@si6networks.com>
Subject: [v6ops] Error in draft-ietf-v6ops-ra-guard-implementation-07
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: Thu, 30 Jan 2014 17:15:04 -0000
Hello, In Section 3, bullet #3, I see: RATIONALE: [RFC6564] specifies a uniform format for IPv6 Extension Header, thus meaning that an IPv6 node can parse an IPv6 header chain even if it contains Extension Headers that are not currently supported by that node. Actually, it's NOT possible for a node to safely parse an IPv6 header chain containing Next Header values that it does not know, even with the uniform TLV format for IPv6 extension headers defined in RFC 6564. The reason for that is because unkown Next Header value could represent an upper-layer protocol rather than an extension header, so it's not safe to attempt to follow the header chain any further. The document is now in AUTH48, so it's still possible to fix the problem before it becomes and RFC. Section 2.1 of RFC 7045 does have an applicable requirement: Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but the default configuration MAY drop such packets. It seems to me that the proper advice for an RA-Guard implementation is to include a configuration switch that specifies whether it passes or discards packets with unknown Next Header values, probably with a default discard. Thoughts? Mike Heard