Re: [v6ops] Error in draft-ietf-v6ops-ra-guard-implementation-07

Joe Touch <touch@isi.edu> Fri, 31 January 2014 17:34 UTC

Return-Path: <touch@isi.edu>
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 63B021A042F for <v6ops@ietfa.amsl.com>; Fri, 31 Jan 2014 09:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level:
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 zJzOL0B0JKLO for <v6ops@ietfa.amsl.com>; Fri, 31 Jan 2014 09:34:21 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 042901A03EC for <v6ops@ietf.org>; Fri, 31 Jan 2014 09:34:20 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s0VHXQVO017270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Jan 2014 09:33:26 -0800 (PST)
Message-ID: <52EBDE66.7010306@isi.edu>
Date: Fri, 31 Jan 2014 09:33:26 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "C. M. Heard" <heard@pobox.com>, V6OPS <v6ops@ietf.org>
References: <Pine.LNX.4.64.1401300857260.25041@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.64.1401300857260.25041@shell4.bayarea.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Fernando Gont <fgont@si6networks.com>
Subject: Re: [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: Fri, 31 Jan 2014 17:34:22 -0000

On 1/30/2014 9:14 AM, C. M. Heard wrote:
> 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 header chain parsing at intermediate nodes is supposed to stop 
before the destination option headers (from the definition of 
destination options RFC2460).

If that rule were followed, there wouldn't be a problem. Or this RFC, 
AFAICT.

Joe