Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

Fernando Gont <fgont@si6networks.com> Wed, 31 October 2012 18:34 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3583B21F8865 for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 11:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+St1zf56HmI for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 11:34:43 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 93F1B21F881F for <v6ops@ietf.org>; Wed, 31 Oct 2012 11:34:43 -0700 (PDT)
Received: from r186-52-22-47.dialup.adsl.anteldata.net.uy ([186.52.22.47] helo=[192.168.51.104]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from <fgont@si6networks.com>) id 1TTd7X-0003Ey-Jo; Wed, 31 Oct 2012 19:34:32 +0100
Message-ID: <50916F21.6030303@si6networks.com>
Date: Wed, 31 Oct 2012 16:34:09 -0200
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <CAKD1Yr13cNspdWvTaXxHt4R_8UB-CKeA4nq8_XWrkbFGCgW7Gg@mail.gmail.com> <5090DECF.3050100@gmail.com> <CAKD1Yr1dUy-f78A2+kfA7NjpzD0WQRT8iwqGYAm5A=Erodpn-A@mail.gmail.com> <20121031.122110.41655699.sthaug@nethelp.no> <50910E41.2030100@gmail.com> <CAKD1Yr0mTTcVeq+Qf0fLv3UCBP_90QmStkK3Ha4tDdm3FxJjVA@mail.gmail.com> <50915F86.7050304@gmail.com> <509165B8.404@si6networks.com> <509169C2.9040208@isi.edu>
In-Reply-To: <509169C2.9040208@isi.edu>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 31 Oct 2012 18:34:44 -0000

On 10/31/2012 04:11 PM, Joe Touch wrote:
> Yes, but the whole point of the IPv6 option architecture was to avoid
> the issues seen with IPv4 options.

The only thing in that IPv6 would avoid is requiring routers to parse
*all* options, just to find the ones that need to be processed by routers.

While the IPv6 extension header syntax is good in terms of extensibility
(in principle, you can include as many options as you want9, it also
allows for pathological cases in which the header chain is split among
multiple fragments (we're working on fixing that one), and also requires
any box that wants to find the upper-layer header to parse the entire
IPv6 header chain -- something that a large number of devices cannot do
at wire speed.

For filtering purposes, it'd been interesting to have a pointer to the
upper-layer header -- although with the original specs, it might simply
not be there. With IPv4, at the very least it's trivial to find the
upper layer protocol: just skip the first IHL of the packet, and you're
there. With IPv6, at leasts in theory, it might be impossible (unless
you reassemble-filter-and-refragment).



> Consider that:
> 
>     - routers don't like fragments because they can't inspect them
> 
>     - so we tunnel and fragment in a higher level protocol
> 
>         the router now needs to implement the higher protocol
>         and still fragment or else we cannot have tunnels
> 
>         the routers on the path still cannot inspect the
>         higher-level fragments
> 
> So we're back to the reason this all breaks - routers doing something
> that we simply cannot support in the architecture.

It's probably time to accept that firewalls and routers implementing
ACLs are part of the architecture. One might argue that the use of
firewalls couldn't be foreseen with IPv4. But at the time IPv6 was
designed, it was already a reality.

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