Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:[email protected]] > Sent: Wednesday, July 10, 2013 8:50 AM > To: Templin, Fred L; Doug Barton > Cc: [email protected] > Subject: RE: Meta-issues: On the deprecation of the fragmentation > function > > Fred, > > There are alternatives.... > > Probably, the best alternative is for the tunnel ingress router to > tunnel ingress router to discover the PMTU to the egress. When the > tunnel ingress router receives a packet that is so large that it cannot > be forwarded through the tunnel, it discards the packet and sends an > ICMP PTB to the packet's originator. The packet's originator then > modifies its sending behavior based upon its new estimate of the PMTU > associated with the destination.
Sure, the tunnel ingress can probe the path to the egress; such a probing method is already covered by SEAL. But, if the path MTU will not accommodate a packet that after encapsulation is as large as (1280 + HLEN) there is no alternative for the ingress other than to start fragmenting since the ingress is not allowed to send a PTB message reporting a size smaller than 1280. > So, for the purposes of MTU management, the tunnel is just another > link. True, but I want that link to have an unbounded MTU. In other words, encapsulate and send everything regardless of its size even if a little bit of fragmentation is necessary (but try to tune out the fragmentation if possible). You should really have a look at my new draft: http://tools.ietf.org/html/draft-generic-6man-tunfrag-08 Thanks - Fred [email protected] > Ron > > > > > > -----Original Message----- > > From: Templin, Fred L [mailto:[email protected]] > > Sent: Wednesday, July 10, 2013 10:59 AM > > To: Ronald Bonica; Doug Barton > > Cc: [email protected] > > Subject: RE: Meta-issues: On the deprecation of the fragmentation > > function > > > > Hi Ron, > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf > > > Of Ronald Bonica > > > Sent: Tuesday, July 09, 2013 5:33 PM > > > To: Doug Barton > > > Cc: [email protected] > > > Subject: RE: Meta-issues: On the deprecation of the fragmentation > > > function > > > > > > Doug, > > > > > > Let's see if we can find some common ground. > > > > > > Assume that the IETF is considering a new protocol that doesn't run > > > over TCP. In order to deal with MTU issues, the new protocol must > do > > > one of the following: > > > > > > a) implement PLMTUD or PMTUD > > > b) restrict itself to sending PDUs so small that when they are > > > encapsulated in an IPv6 header, the resulting packet will not > exceed > > > 1280 bytes > > > c) rely on IPv6 fragmentation > > > > > > Is there ever a reason why c) is better than a) or b). For that > > > matter, is c) ever an acceptable solution? > > > > Fragmentation at a tunnel ingress router is unavoidable. Proof: > > > > - a tunnel configures a 1280 MTU > > - When its packets are encapsulated they emerge as (1280 + HLEN) > > (the length of the encapsulating headers) > > - the tunnel crosses a 1280 link somewhere in the path to the > egress > > - the packet is dropped with a PTB signal sent back > > - the ingress now has two choices: 1) start fragmenting, 2) quit. > > > > Thanks - Fred > > [email protected] > > > > > Ron > > > > > > > -----Original Message----- > > > > From: Doug Barton [mailto:[email protected]] > > > > Sent: Tuesday, July 09, 2013 2:41 PM > > > > To: Ronald Bonica > > > > Cc: [email protected] > > > > Subject: Re: Meta-issues: On the deprecation of the fragmentation > > > > function > > > > > > > > On 07/09/2013 11:12 AM, Ronald Bonica wrote: > > > > > Doug, > > > > > > > > > > It might be interesting to revisit what we mean by deprecating > > > > > IPv6 > > > > fragmentation.... > > > > > > > > > > It means that the IETF will not approve any new protocols that > > > > > rely > > > > upon IPv6 fragmentation. Nothing more, nothing less. > > > > > > > > Thanks for clarifying. FWIW, I understand what is being proposed, > > > > and > > > I > > > > still think it's a bad idea. > > > > > > > > Doug > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > - > > > IETF IPv6 working group mailing list > > > [email protected] > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > ------------------------------------------------------------------- > - > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
