Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt)

[Fred Templin]

Folks,

 

I uncovered a few bugs and made some changes since yesterday.

(I was using the wrong mechanism for L2 fragmentation! :^/ ) The

new document version can be found at:

 

  www.geocities.com/osprey67/tunnelmtu-04.txt

 

The changelog appears below:

 

Fred

[EMAIL PROTECTED]

 

Appendix 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 this

message and my current document are not. See:

 

www.geocities.com/osprey67/tunnelmtu-03.txt

 

This document offers the following important conclusion:

 

  "It is impossible for the network to anticipate the

   packet transmission strategy of the application."

 

This result is perhaps not surprising and certainly not new, as

it is accurately predicted by the End-to-End Principle.

 

Some additional notes:

 

- For the past several months, I have worked under the premise that a

  robust, secure, efficient, and generalized Path MTU discovery mechanism

  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without

  direction from the application. I struggled for many months to come up

  with a solution that satisfied this design point and failed -  as have many

  others over the past 15 years.

 

- After finally accepting the above conclusion and recognizing the means

  by which the application could provide guidance to the network, the solution

  was immediately obvious and I was able to write the entire document on

  the 4.5 hr flight into Minneapolis.

 

All those interested in path MTU discovery (and the more general

subject of application<->network interactions) should read this

document along with the normative references it cites (even reading

just the Introduction should be sufficient if time is short). The document

probably has a few bugs, and I would appreciate comments. But,

the conclusions will not go away and are indeed inescapable.

 

Thanks - Fred

[EMAIL PROTECTED]

 

P.S. The document can be trivially extended to support IPv6

    Jumbograms - 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 under

the subject heading: "Re: RFC 2461bis issue: MTU handling", I am

now prepared to submit a new version of my document on dynamic

MTU determination. (Please note that there are some significant

differences from the previous version.)

 

A copy of the document can be viewed at:

 

  www.geocities.com/osprey67/tunnelmtu-03.txt

 

I am copying this to both lists, but suggest we continue

the discussion on 'v6ops'. Finally, I would like to welcome

comments and offer this document as topic for discussion

during the MECH timeslot in Tuesday's v6ops session.

 

Fred Templin

[EMAIL PROTECTED]