Re: draft-bonica-6man-frag-deprecate

Antonios Atlasis <antonios.atlasis@gmail.com> Thu, 27 June 2013 18:33 UTC

Return-Path: <antonios.atlasis@gmail.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 BF17121F9D6A for <ipv6@ietfa.amsl.com>; Thu, 27 Jun 2013 11:33:00 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 d3du5Kp1PZnD for <ipv6@ietfa.amsl.com>; Thu, 27 Jun 2013 11:33:00 -0700 (PDT)
Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C78C921F9D5F for <ipv6@ietf.org>; Thu, 27 Jun 2013 11:32:59 -0700 (PDT)
Received: by mail-qa0-f45.google.com with SMTP id ci6so2699667qab.18 for <ipv6@ietf.org>; Thu, 27 Jun 2013 11:32:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gyO7S9l9hKN6MDVArUkmjjYcB/cY+FE+oAbj6OAtb6U=; b=HFsY42kHeE11XG0Sjk5n/cCD0AbUxzUq0b21ln4LpkQldaJF7ySqDHDYz1TLRDf/58 J9HzNU8ffeX5huqcLmCgY529UIoYk4jUdQMT0/jTq/xyIyRqJLLPetzinV2J2UyW2/BC 1qlU9uQJMxSs8KfuJZPeBK8R1KUHJ6N9pbEtsHWZHyhSHdfR0KjK4FHXOa4j08YqJyVr Akgct/u/oed6ZwyHYiX+XEJAqv8iZdzPiut1mISUBAT0zi6rX0V1r6tGFIkjmLfgkW5c sZGFhWmWNpMVYURR7RBVa7Y8lEN5dHunx5ZdDwbi0VbQasVkzkePMC4U/jhDwFUPaJ00 B+ww==
MIME-Version: 1.0
X-Received: by 10.49.98.196 with SMTP id ek4mr12665198qeb.8.1372357979250; Thu, 27 Jun 2013 11:32:59 -0700 (PDT)
Received: by 10.224.184.79 with HTTP; Thu, 27 Jun 2013 11:32:59 -0700 (PDT)
In-Reply-To: <51CB91E4.5090603@gmail.com>
References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C32FA9.1090207@gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F85F38@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <m24ncmaozs.wl%randy@psg.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <m2li5yj7u3.wl%randy@psg.com> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <m2ehbpij86.wl%randy@psg.com> <51CB91E4.5090603@gmail.com>
Date: Thu, 27 Jun 2013 21:32:59 +0300
Message-ID: <CADoTVZLe=dm+JhMSAxFiAYpUMG=T-cUFdtkdHtmzmebG9=Dujw@mail.gmail.com>
Subject: Re: draft-bonica-6man-frag-deprecate
From: Antonios Atlasis <antonios.atlasis@gmail.com>
To: ipv6@ietf.org
Content-Type: multipart/alternative; boundary="047d7bdcace4dba65504e026fd41"
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: Thu, 27 Jun 2013 18:33:00 -0000

Hi,

there are certainly many security issues in IPv6 related with
fragmentation, but still not convinced if its use should be deprecated
completely. We should not remove any feature that may cause security
issues. We may need it some day. On the contrary, I believe that we should
try to fix it.

I believe that some of the draft RFCs proposed by Fernando Gont are in the
good direction (regarding the RA-Guard case, the generation of the fragment
id values, etc), as well as the newly accepted RFC regarding the handling
of atomic fragments.   Apart from the above, what remains to be fixed, in
my humble opinion, are the following:

a. Tiny fragments (smaller than 1280 bytes) should not be accepted (unless
they are atomic fragments or the last fragment of a datagram).
b. RFC 5722 should be updated so as only the overlapping fragments to be
dropped, not all the ones already received, or the ones that follow (as it
is the recommendation now). This is already implemented by FreeBSD and
seems to me the most proper way for handling overlapping fragments.

We should also never forget that the rest of IPvt6Extension headers can
result in datagrams much bigger than 1280 bytes, 1500 bytes, or even more.
So, if you want to deprecate fragmentation in IPv6, you should also
deprecate or at least change the extension headers usage in IPv6. Which
actually means, redesign IPv6.

Just my 0.02$


Antonios


2013/6/27 Brian E Carpenter <brian.e.carpenter@gmail.com>

> Cutting to the chase, and assuming that the next version
> will have more analysis and observational evidence, I'm thinking
> something like the following:
>
> 3.  Recommendation
>
>    This memo deprecates IPv6 fragmentation and the IPv6 fragment header.
>    Application and transport layer protocols SHOULD support effective
>    PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981]
>    is unreliable. Any application or transport layer protocol that
>    cannot support effective PMTU discovery MUST NOT in any circumstances
>    send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes.
>
>    IPv6 stacks and forwarding nodes SHOULD continue to support inbound
>    fragmented IPv6 packets as specified in [RFC2460]. However, this
>    requirement exceeds the capability of some types of forwarding node
>    such as firewalls and load balancers. Therefore implementers and
>    operators need to be aware that on many paths through the Internet,
>    IPv6 fragmentation will fail. Legacy applications and transport layer
>    protocols that do not conform to the previous paragraph can expect
>    connectivity failures as a result.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>