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

Folks, I have just received private communication from someone associated with http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf. He informs me that I may have misinterpreted the paper's results. Specifically, packets fragmented to 1280 bytes were filtered on only

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

On Tue, Jun 25, 2013 at 12:27 PM, Templin, Fred L wrote: > Hi, > > I just wanted to put out one thought. When talking about fragmentation > and reassembly, never say "always" and never say "never". It is true > that some routers are not well positioned to perform steady-state > fragmentation and

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

Hi, I just wanted to put out one thought. When talking about fragmentation and reassembly, never say "always" and never say "never". It is true that some routers are not well positioned to perform steady-state fragmentation and reassembly but that does not mean that it should "never" be used for a

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

Brian E Carpenter wrote: > > If it's a statement of fact, it shouldn't use RFC 2119 language. It > should simply state the truth: "Network operators might filter IPv6 > fragments." +1 -- John Leslie IETF IPv6 working group

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

In message , Randy Bush writes: > > If it's a statement of fact, it shouldn't use RFC 2119 language. It > > should simply state the truth: "Network operators might filter IPv6 > > fragments." > > s/might/do/ Which would be a totally mis-leading statement. "Some network operators filter IPv6 fra

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

On 6/24/13 12:19 PM, Marc Lampo wrote: -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 se

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

> If it's a statement of fact, it shouldn't use RFC 2119 language. It > should simply state the truth: "Network operators might filter IPv6 > fragments." s/might/do/ IETF IPv6 working group mailing list ipv6@ietf.org Administrati

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

On 25/06/2013 10:11, Ronald Bonica wrote: >> "New IPv6 host implementations MAY support IPv6 fragmentation and >> reassembly" >> break things. "New IPv6 host implementations MAY support IPv6 >> fragmentation but MUST support reassembly" may superior. This will >> aging out fragmentation over a long

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

> > "New IPv6 host implementations MAY support IPv6 fragmentation and > reassembly" > break things. "New IPv6 host implementations MAY support IPv6 > fragmentation but MUST support reassembly" may superior. This will > aging out fragmentation over a longer period, new hosts will not use it > but e

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

* Hagen Paul Pfeifer | 2013-06-24 22:40:09 [+0200]: >I'm a little bit sad about this incompatible protocol change/break. >Fragmentation was an early design failure in IPv4 - for IPv6 fragmentation it >is still supported and I see no way to obsolete fragmentation without >incompatible protocol cha

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

* Ronald Bonica | 2013-06-21 19:00:51 [+]: >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 One of my clients using exten

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

o: Ronald Bonica >Cc: "ipv6@ietf.org 6man-wg" >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)

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 sho

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

etf.org 6man-wg > Subject: Re: FW: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt > > * Ronald Bonica > > > [draft-bonica-6man-frag-deprecate] > > Being an operator I would definitively welcome getting rid of the > complexities dealing with IPv6

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

In message <51c7a69f.40...@dougbarton.us>, Doug Barton writes: > Given that larger and faster pipes are becoming more common, and given > that we know that larger packet sizes make for more efficient > utilization of those pipes, IMO it's a really bad idea to "give up the > fight" at this early

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

n, Fred L > Sent: Monday, June 24, 2013 7:02 AM > To: Ronald Bonica > Cc: ipv6@ietf.org 6man-wg > Subject: RE: FW: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt > > Hi, > > Deprecation of IPv6 fragmentation would make life difficult for IPv6 > tu

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

On 06/21/2013 01:52 PM, Brian E Carpenter wrote: On 22/06/2013 07:53, Ronald Bonica wrote: I don't 100% agree. In the case that PMTUD is broken, there'd be nothing to stop a current DNSSEC implementation from always assuming a default path MTU of 1280, without awaiting confirmation from PMTUD, a

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

Hi, Deprecation of IPv6 fragmentation would make life difficult for IPv6 tunnels. For tunnels that span paths with ~1280 MTUs, the tunnel ingress' only option is to fragment since it is not permitted to return a PTB with MTU less than 1280. See RFC2473 for example of a normative specification that

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

; > To: Ronald Bonica > > Cc: Ray Hunter; ipv6@ietf.org 6man-wg > > Subject: Re: FW: New Version Notification for draft-bonica-6man-frag- > > deprecate-00.txt > > > > On 22/06/2013 07:53, Ronald Bonica wrote: > > >> I don't 100% agree. I

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

* 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 protocol

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

> -Original Message- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Friday, June 21, 2013 4:53 PM > To: Ronald Bonica > Cc: Ray Hunter; ipv6@ietf.org 6man-wg > Subject: Re: FW: New Version Notification for draft-bonica-6man-frag- > deprecate

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

On 22/06/2013 07:53, Ronald Bonica wrote: >> I don't 100% agree. In the case that PMTUD is broken, there'd be >> nothing to stop a current DNSSEC implementation from always assuming a >> default path MTU of 1280, without awaiting confirmation from PMTUD, and >> fragmenting the UDP packet pre-emptiv

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

> I don't 100% agree. In the case that PMTUD is broken, there'd be > nothing to stop a current DNSSEC implementation from always assuming a > default path MTU of 1280, without awaiting confirmation from PMTUD, and > fragmenting the UDP packet pre-emptively [assuming fragmentation was > not equally

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

> Ronald Bonica > 21 June 2013 21:12 > Ray, > > Joel has already responded regarding DNSSEC. However, I would like to > add a word regarding PMTUD brokenness. > > If the bad operator behavior to which you refer is the filtering of > ICMP PTB messages, that bad behavior

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

pv6@ietf.org 6man-wg > Subject: Re: RE: FW: New Version Notification for draft-bonica-6man- > frag-deprecate-00.txt > > I have also read this draft. > > It mentions that DNSSEC will be impacted. > > What's the alternative if DNSSEC can't send multiple UDP fragmen

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

> -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Arturo Servin > Sent: Thursday, June 20, 2013 12:37 PM > To: ipv6@ietf.org > Subject: Re: FW: New Version Notification for draft-bonica-6man-frag- > deprecate-00

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

On 6/21/13 10:03 AM, Ray Hunter wrote: I have also read this draft. It mentions that DNSSEC will be impacted. What's the alternative if DNSSEC can't send multiple UDP fragments? so I'm pretty sure I don't want to expose myself to really big replies because that pushed the opportunity to amplif

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

I have also read this draft. It mentions that DNSSEC will be impacted. What's the alternative if DNSSEC can't send multiple UDP fragments? Isn't expecting a busy DNS server to maintain TCP session state for every single query going to be prohibitively expensive? Leading to even bigger DoS worrie

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

pv6@ietf.org 6man-wg > Subject: Re: FW: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt > > I really like this idea. > What worries me is the different cases to be examined/solved depending > on the source device: host (applications) or router (protocols

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

Le 2013-06-21 10:03, Tassos Chatzithomaoglou a écrit : I really like this idea. +1 What worries me is the different cases to be examined/solved depending on the source device: host (applications) or router (protocols). And this draft takes into account mostly the first. Impacts on SIIT [RF

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

I really like this idea. What worries me is the different cases to be examined/solved depending on the source device: host (applications) or router (protocols). And this draft takes into account mostly the first. -- Tassos Ronald Bonica wrote on 20/06/2013 18:55: > Folks, > > Please review this

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

Ron, Warren In general I tent to agree with you. Would you have references or data to back up these two statements? 1) " Most popular TCP [RFC0793] implementations leverage this technology and restrict their segment size so that IP fragmentation is not required." 2) " As a result,