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

[Erik Nordmark <Erik.Nordmark@sun.com>]

> 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