Re: Unknown header extension or option

Fernando Gont <fgont@si6networks.com> Sat, 22 November 2014 14:36 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6081AC3C0 for <ipv6@ietfa.amsl.com>; Sat, 22 Nov 2014 06:36:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Kt3hcLFGgebV for <ipv6@ietfa.amsl.com>; Sat, 22 Nov 2014 06:36:12 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6CB1AC3BC for <ipv6@ietf.org>; Sat, 22 Nov 2014 06:36:12 -0800 (PST)
Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XsBn0-0007rr-37; Sat, 22 Nov 2014 15:35:54 +0100
Message-ID: <54709F3F.10209@si6networks.com>
Date: Sat, 22 Nov 2014 04:35:43 -1000
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>, Erik Nordmark <nordmark@acm.org>
Subject: Re: Unknown header extension or option
References: <54667C2C.6000509@gmail.com> <5466AB5C.9070806@acm.org> <D08FE588.32D32%evyncke@cisco.com> <CAESTAVuf=Bw3F4R-qc=o5m5iRzTJFRM1PXr7ORGM354rYovpJw@mail.gmail.com> <A190841A-32E5-423E-BA58-FB816227AB0A@cisco.com> <00423ECC-0B11-40AF-9AE4-E6577B0DBE77@townsley.net> <A3FE6519-0089-45D5-831C-A1CAB57473F8@cisco.com> <6E6055FF-09A0-4323-9570-4B8CD033CC26@townsley.net> <2434FDC7-A918-4FC0-BBD8-708FBC08A79F@cisco.com> <F23BC0AC-0785-41BC-A493-1D1A3037FA2C@cisco.com> <546AA4E4.8000801@acm.org> <FD369FCD-D366-4B59-A1C7-3B8B168A9536@cisco.com>
In-Reply-To: <FD369FCD-D366-4B59-A1C7-3B8B168A9536@cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/BN7K_32SdqM11uiGWQ7fF4t0X6Y
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Nov 2014 14:36:15 -0000

Hi, Fred,

On 11/17/2014 04:24 PM, Fred Baker (fred) wrote:
>> 
>> I haven't re-read RFC 2460 but I'm pretty sure that the preamble 
>> "is required to proceed" above is supposed to handle this. A
>> router is only "required to proceed" past the IPv6 header if -
>> the packet is explicitly addressed to (one of) the router's IPv6
>> address(es) (which was the case for routing headers) - the packet
>> has a hop-by-hop options header
>> 
>> But a router must implement HBH. And if the packet has a routing 
>> header then there is not need for the router to look at the
>> header after the RH unless segments left = 0 (i.e., the router is
>> at the final destination of the RH path).
>> 
>> So if the world only has hosts and routers I think the text if 
>> fine.
> 
> Well, I’m not so sure. I’d suggest you re-read 
> https://tools.ietf.org/html/rfc2460#section-4
> 
> It doesn’t refer to a router or a host; it refers to a node. The 
> context is not “going beyond the IPv6 header to TCP-or-whatever”.
> It is “I processed the base IPv6 header or some extension header,
> for whatever reason I need to go to the next extension header, and
> I don’t understand it.”
> 
> Extension headers invariable have as their first two bytes:
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  Next Header  |  Hdr Ext Len
> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

They don't. Please check
<http://tools.ietf.org/id/draft-gont-6man-ipv6-universal-extension-header-01.txt>



> Now, everyone gets their own opinion of SRH, and personally I’m
> not sure I see why the considerations of RFC 5095 don’t apply. 
> None-the-less, I’m wondering what happens when we do get a new 
> extension header. I’m not sure it’s good. If we are trying to
> deploy a new extension header and it is presented to an unupdated
> system, we get a parameter problem, not a robust response.

This is also discussed in the aforementioned I-D.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492