So I'm generally ok with it, more because I think a reasonable proportion of administers of the network are effectively deprecating features that rely on the network behaviour by prohibiting them.
I've noticed that a number of mechanisms have been developed for hosts to either more actively measure the capabilities of the network between the intended communications end points and then take action to overcome them (the variety of NAT traversal methods, ICMP-less PMTUD), or at least assume a limitation and take actions to overcome or avoid them (happy eyeballs, multipath TCP). I think the rapid adoption of mobile multihomed hosts (i.e., smartphones and tablets) means that we will see hosts be smarter about these network limitations, because their connectivity to the network varies much more than it used to - they may have one or more connections to the network, and the quality and capability of those connections will vary. It seems as the network is ending up with more varying levels of "dumbness" (intentional or not), the hosts will get and are getting smarter. Regards, Mark. >________________________________ > From: Marc Lampo <marc.lampo.i...@gmail.com> >To: Ronald Bonica <rbon...@juniper.net> >Cc: "ipv6@ietf.org 6man-wg" <ipv6@ietf.org> >Sent: Tuesday, 25 June 2013 5:19 AM >Subject: Re: FW: New Version Notification for >draft-bonica-6man-frag-deprecate-00.txt > > > >-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 >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
