Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

Tore Anderson <tore@fud.no> Sat, 22 June 2013 09:29 UTC

Return-Path: <tore@fud.no>
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 A35E421F9D55 for <ipv6@ietfa.amsl.com>; Sat, 22 Jun 2013 02:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 nujgXFsDWZa9 for <ipv6@ietfa.amsl.com>; Sat, 22 Jun 2013 02:29:12 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id F004821F9D50 for <ipv6@ietf.org>; Sat, 22 Jun 2013 02:29:07 -0700 (PDT)
Received: from [2a02:fe0:cf16:20:21d:60ff:fe48:f59e] (port=37634 helo=wrath.fud.no) by greed.fud.no with esmtpa (Exim 4.80) (envelope-from <tore@fud.no>) id 1UqK80-0001Wz-7y; Sat, 22 Jun 2013 11:29:04 +0200
Message-ID: <51C56E60.5040009@fud.no>
Date: Sat, 22 Jun 2013 11:29:04 +0200
From: Tore Anderson <tore@fud.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: Ronald Bonica <rbonica@juniper.net>
Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com>
In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: "ipv6@ietf.org 6man-wg" <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, 22 Jun 2013 09:29:12 -0000

* Ronald Bonica

> [draft-bonica-6man-frag-deprecate]

Being an operator I would definitively welcome getting rid of the
complexities dealing with IPv6 fragments bring. That said, the draft
needs additional discussion on this could be accomplished without
breaking assumptions made by other protocols, though.

On my network, I have two legitimate consumers of IPv6 fragments:

1) OSPFv3. RFC 2740 A.1 says «OSPF does not define a way to fragment its
protocol packets, and depends on IPv6 fragmentation when transmitting
packets larger than the link MTU». It does goes on to say «the OSPF
packet types that are likely to be large [...] can usually be split into
several separate protocol packets, without loss of functionality. This
is recommended; IPv6 fragmentation should be avoided whenever possible».
In my experience however, the implementation vendors appears to have
skipped over that last recommendation.

2) SIIT (RFC 6145). There are several corner cases where a SIIT
translator, or an IPv6 node communicating with an IPv4 node through such
a translator, have to deal with IPv6 fragments. In particular:

- When a SIIT translator receives an IPv4 packet with DF=0 that would
result in an IPv6 packet that would exceed the IPv6 link MTU, it will
split the original packet into IPv6 fragments.

- When a SIIT translator receives an IPv4 fragment, it will translate
this into one or more IPv6 fragments.

- When the SIIT translator receives an IPv4 packet with DF=0 it «SHOULD
always include an IPv6 Fragment Header to indicate that the sender
allows fragmentation». (I wouldn't miss this feature going away though,
as I disable it anyway.)

- When an IPv6 node receives an ICMPv6 Packet Too Big message indicating
a Path MTU less than 1280, it should either 1) simply heed the indicated
Path MTU, or 2) limit the size of subsequent transmitted packets to 1280
and include a Fragmentation header (w/MF=0, i.e., an "atomic" fragment)
in them. See RFC 2460 section 5. I know that Linux takes this second
approach, at least.

I cannot support your draft until it discusses or provides solutions for
the above considerations.

Finally I'll note that in all of the above cases, the use of IPv6
fragments is limited to within a single administrative domain (i.e., my
network), so the rationale that IPv6 fragmentation does not work over
the Internet does not really apply.

Best regards,
Tore Anderson