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
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 PROTECTED]
Appendix A. Changelog o Removed support for IPv4 fragmentation to save state; eliminated control message overhead.
Fred
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:
www.geocities.com/osprey67/tunnelmtu-04.txt
As to how the near endpo
On Tue, 11 Nov 2003, Erik Nordmark 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
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. Changel
> 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 v
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 PROTECTED]Fred Templin <[EMAIL PROTECTED]> wrote:
P.S. The document can be trivially ext
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 i
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.)
