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

[Fred Templin <osprey67@yahoo.com>]

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

osprey67@yahoo.com

 

See below:

Erik Nordmark <Erik.Nordmark@sun.com> 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.)

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------