I have one more update to share on this document. It is found at:
Changelog is below:
Fred Templin
Appendix A. Changelog
o Removed support for IPv4 fragmentation to save state; eliminated
control message overhead.
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