Yes, it's me again - hopefully one last time. I took out a bit too much in
my last iteration on the document. I have added the following new text
under "Sending Packets:"
"If the packet is 1280 bytes in length and it contains an IPv6
fragment header, the tunnel interface encapsluates the packet
in IPv4 then fragments the encapsulated packet to a fragment
size of 256 bytes. Each of the five resulting fragments will
add a 20 byte IPv4 fragment header making each fragment 276
bytes. Thus, each fragment will fit within the ~200msec human
perceptible delay budget for the lowest-common denominator
link that may occur over the tunnel, which is 296 bytes for
a 9.6kbps link ([RFC3150], section 2.3)."
See:
Thanks - Fred
I have one more update to share on this document. It is found at:Changelog is below:Fred TemplinAppendix A. Changelog
o Removed support for IPv4 fragmentation to save state; eliminated
control message overhead.
Fred Templin <[EMAIL PROTECTED]> wrote:Folks,I uncovered a few bugs and made some changes since yesterday.(I was using the wrong mechanism for L2 fragmentation! :^/ ) Thenew document version can be found at:The changelog appears below:FredAppendix A. Changelog
o Specified use of IPv4 fragmentation (instead of IPv6) as the L2
fragmentation mechanism.
o Added CongestMTU for use during periods of congestion.
o Added support for sending congestion indications not associated
with probes.
o Clarified DF bit settings.
Fred Templin <[EMAIL PROTECTED]> wrote:I would like to add some qualifying remarks to my previous message.Many of my earlier messages on this subject were preliminary, but thismessage and my current document are not. See:This document offers the following important conclusion:"It is impossible for the network to anticipate thepacket transmission strategy of the application."This result is perhaps not surprising and certainly not new, asit is accurately predicted by the End-to-End Principle.Some additional notes:- For the past several months, I have worked under the premise that arobust, secure, efficient, and generalized Path MTU discovery mechanismfor IPv6-in-IPv4 tunnels was needed that operated autonomously and withoutdirection from the application. I struggled for many months to come upwith a solution that satisfied this design point and failed - as have manyothers over the past 15 years.- After finally accepting the above conclusion and recognizing the meansby which the application could provide guidance to the network, the solutionwas immediately obvious and I was able to write the entire document onthe 4.5 hr flight into Minneapolis.All those interested in path MTU discovery (and the more generalsubject of application<->network interactions) should read thisdocument along with the normative references it cites (even readingjust the Introduction should be sufficient if time is short). The documentprobably has a few bugs, and I would appreciate comments. But,the conclusions will not go away and are indeed inescapable.Thanks - FredP.S. The document can be trivially extended to support IPv6Jumbograms - this will be added in the next version.
Fred Templin <[EMAIL PROTECTED]> wrote:As I said I would do in my 10/29/2003 note on the ipv6 list underthe subject heading: "Re: RFC 2461bis issue: MTU handling", I amnow prepared to submit a new version of my document on dynamicMTU determination. (Please note that there are some significantdifferences from the previous version.)A copy of the document can be viewed at:I am copying this to both lists, but suggest we continuethe discussion on 'v6ops'. Finally, I would like to welcomecomments and offer this document as topic for discussionduring the MECH timeslot in Tuesday's v6ops session.Fred Templin