Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt

From: Fred Templin <[email-masked]>
Date: Sun, 9 Nov 2003 21:14:19 -0800 (PST)

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-masked]

---

From: Fred Templin <[email-masked]>
Date: Mon, 10 Nov 2003 09:33:14 -0800 (PST)

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:

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-masked]
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 

Fred Templin <[email-masked]> wrote:

 
 
Fred Templin
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Mon, 10 Nov 2003 13:17:21 -0800 (PST)

Hmm - I may have spoken too soon, as it looks like RFC 2675 has
some minimum packet sizing requirements that make it just a bit
too big to use over IPv6-in-IPv4 tunnels. Maybe we should (bis) it?
 
Fred
[email-masked]

Fred Templin <[email-masked]> wrote:
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Nov 2003 17:32:29 +0100 (CET)

> differences from the previous version.)

I looked over the your document and I wonder how it applies to the WG's
desire to clarify the transition mechanisms document and move that
to Draft Standard soon. 

Thus I recommend the WG participants read the document so we can
discuss that high-level issue on Wednesday.

From one reading I see:
Using period(?) hop-by-hop options in data packets to probe the IPv6
path MTU; those packets would be processed slowly by IPv6 routers.

IPv6 fragmentation by IPv6 routers; not allowed per RFC 2460

Assuming security associations between the encapsulator and decapsulator

Having decapsulators that are otherwise hosts send Router Advertisements seems
a bit odd.

I don't understand how the IPv4 path MTU is detected by the 
encapsulator/decapsulator somehow. Is this based on ICMPv4 packet too big
message or something else?

  Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Templin <[email-masked]>
Date: Tue, 11 Nov 2003 08:37:05 -0800 (PST)

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-masked]
 
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.

 

 
Some additional notes:

 
 
Thanks - Fred
[email-masked]

 

 
Fred Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Nov 2003 19:22:46 +0200 (EET)

> desire to clarify the transition mechanisms document and move that

I completely agre with this sentiment.  This enhanced MTU discovery is way
too much of a moving target to be included at this point.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Templin <[email-masked]>
Date: Tue, 11 Nov 2003 09:47:50 -0800 (PST)

Erik,
 
Thanks for the comments; as you may have seen I just posted an update
to the document that fixes at least one of the issues you have identified
(the  new version is using the correct L2 fragmentation mechanism). See:

As to how the near endpoint of the tunnel detects the MTU of the IPv4 path
to the far endpoint, it is done via authenticated IPv6 Router Advertisement
messages from the far end that encode MTU values. One of the MTU values
is a measure of the largest packet (or, packet fragment) that has been
observed by the far end to traverse the tunnel in one piece, and the other
two MTU values provide an indication of the far end's receive buffer size
and fragment loss due to congestion.
 
Thanks - Fred
[email-masked]
 
See below:

From one reading I see:

Erik

---

From: Fred Templin <[email-masked]>
Date: Wed, 12 Nov 2003 08:18:20 -0800 (PST)

I have one more update to share on this document. It is found at:
 
  www.geocities.com/osprey67/tunnelmtu-05.txt
 
Changelog is below:
 
Fred Templin
[email-masked]
 
Appendix A. Changelog

   o  Removed support for IPv4 fragmentation to save state; eliminated
      control message overhead.

 

Fred
[email-masked]
 
Appendix A. Changelog

 

 
 
Some additional notes:

 
 
Thanks - Fred
[email-masked]

 

 
Fred Templin
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Wed, 12 Nov 2003 11:08:45 -0800 (PST)

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:
 
  www.geocities.com/osprey67/tunnelmtu-06.txt
 
Thanks - Fred
[email-masked]

 
Changelog is below:
 
Fred Templin
[email-masked]
 
Appendix A. Changelog

 

 
Fred
[email-masked]
 
Appendix A. Changelog

 

 
 
Some additional notes:

 
 
Thanks - Fred
[email-masked]

 

 
Fred Templin
[email-masked]