-1 Not because I'm a fan of fragmentation, but I think a layer 3 (IP) protocol that does not support fragmentation should really be a *new* IP version. In my opinion, the changes are too dramatic : if layer 3, not supporting fragmentation, is asked to sent a message, too big for one packet, it should inform layer 4 with an error message; while a layer 3 that supports fragmentation, can fragment and send in multiple packets (and return succes to layer 4).
I can imagine case exist - without searching for explicit examples, some already given or hinted at by others in this discussion - where two partners in a conversation cannot communicate (perhaps only simplex ?) because one is implemented on a host that implements IPv6 with fragmentation and the other on a host that implements IPv6 without fragmentation. I do agree that fragmentation introduces attack vectors, but allowing that hosts do not implement it is, for me, not the correct approach. I'd prefer to insist that all headers, up till and including the layer 4, are in the first fragment and that implementations provide correct implementation of fragmentation. (both suggestions merely a repetition of other contributors in this discussion) In one of the replies you, Ron, write : > I don't know of a study. However, this is probably a safe assumption considering that: > > - many TCP implementation leverage PMTUD > - many enterprise block fragments > - many firewalls, by default, block IPv6 fragments I cannot comment on the first point. My experience with enterprises is that firewalls used normally cope well with fragments (in the sense that they can flow through) ((perhaps in the old days, before "stateful inspection", with basic ACL's; but even a cheap home router copes with (IPv4) fragmentation)) As for point 3 : when I look at firewall capabilities concerning IPv6 I actually look if it is possible to allow *only* the fragmentation extension header (as, in my opinion, it is the only extension header needed to let the business run) ((a statement that, by itself, might generate discussion - please, in a different thread)) So, as for the list of 3 points, I cannot support this "safe assumption". Kind regards, Marc On Thu, Jun 20, 2013 at 5:55 PM, Ronald Bonica <rbon...@juniper.net> wrote: > Folks, > > Please review this draft and provide comments. > > Ron > > > > -----Original Message----- > > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > > Sent: Thursday, June 20, 2013 11:48 AM > > To: Ronald Bonica > > Subject: New Version Notification for draft-bonica-6man-frag-deprecate- > > 00.txt > > > > > > A new version of I-D, draft-bonica-6man-frag-deprecate-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Filename: draft-bonica-6man-frag-deprecate > > Revision: 00 > > Title: IPv6 Fragment Header Deprecated > > Creation date: 2013-06-20 > > Group: Individual Submission > > Number of pages: 7 > > URL: http://www.ietf.org/internet-drafts/draft-bonica-6man- > > frag-deprecate-00.txt > > Status: http://datatracker.ietf.org/doc/draft-bonica-6man- > > frag-deprecate > > Htmlized: http://tools.ietf.org/html/draft-bonica-6man-frag- > > deprecate-00 > > > > > > Abstract: > > This memo deprecates the IPv6 Fragment Header. It provides reasons > > for deprecation and updates RFC 2460. > > > > > > > > > > > > The IETF Secretariat > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
