Re: 6MAN WG Call for adoption draft-gont-6man-oversized-header-chain-02

Suresh Krishnan <suresh.krishnan@ericsson.com> Sat, 30 June 2012 00:48 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7489211E80A0 for <ipv6@ietfa.amsl.com>; Fri, 29 Jun 2012 17:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.569
X-Spam-Level:
X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rBlWNA-EyiBH for <ipv6@ietfa.amsl.com>; Fri, 29 Jun 2012 17:48:26 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C9F5711E808D for <ipv6@ietf.org>; Fri, 29 Jun 2012 17:48:25 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5U0mMFs026019; Fri, 29 Jun 2012 19:48:23 -0500
Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 29 Jun 2012 20:48:16 -0400
Message-ID: <4FEE4CD0.2060002@ericsson.com>
Date: Fri, 29 Jun 2012 20:48:16 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>
Subject: Re: 6MAN WG Call for adoption draft-gont-6man-oversized-header-chain-02
References: <AB6FAEC8-2486-46A2-9152-C9A376979A54@employees.org> <4FEB6E72.9010601@ericsson.com> <4FEBC589.2020900@si6networks.com>
In-Reply-To: <4FEBC589.2020900@si6networks.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "draft-gont-6man-oversized-header-chain@tools.ietf.org" <draft-gont-6man-oversized-header-chain@tools.ietf.org>, "ipv6@ietf.org Mailing List" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2012 00:48:26 -0000

Hi Fernando,

On 06/27/2012 10:46 PM, Fernando Gont wrote:
> On 06/27/2012 10:34 PM, Suresh Krishnan wrote:
>>
>> I read through the draft and I am generally supportive of the sentiment
>> behind the draft. But the draft itself is not at all clear on what
>> constitutes a "entire IPv6 header chain". Without this, I think the
>> draft in its current form is not actionable. 
> 
> I simply disagree. While I have no objection with including "a crisper
> definition of what 'entire IPv6 header chain'", I think claiming that
> "the draft in current for is not actionable" is taking it way too far.
> For instance, a bunch of people clearly understood what the document is
> talking about -- with the entire IPv6 header chain being all headers
> from the fixed IPv6 header chain, till the upper layer protocol (TCP,
> UDP, etc. -- assuming there's one of those), including any extension
> headers.

This description works for me. Just put it in the draft and we are all set.

> 
> 
> 
>> I would like a crisper
>> definition of what exactly is the expected behavior on sending,
>> receiving and intermediate nodes
> 
> Essentially, what is important is the sending behaviour: You must
> include the entire IPv6 header chain in the first fragment. Intermediate
> nodes may simply forward non-compliant packets, but may also decide to
> drop them -- ditto for end nodes.

I asked because there is a legitimate problem that you raise in Section 4

"However, if the first
   fragment fails to include the entire IPv6 header chain, they may have
   no option other than "blindly" allowing or blocking the corresponding
   fragment.  If they blindly allow the packet, then the firewall can be
   easily circumvented by intentionally sending fragmented packets that
   fail to include the entire IPv6 header chain in the first fragment."

but the draft does nothing to mitigate this issue.

Thanks
Suresh