mech-v2: static MTU scope; feedback sought

[Pekka Savola <pekkas@netcore.fi>]

Hi,

There's still one (the most difficult IMO) issue in transmech-v2 
update, triggered by Dave Thaler's comment:

http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01717.html

That is, a node with v4-in-v6 tunnel, v4 interface, and a v6-in-v6
MIPv6 tunnel: using default MTU 1280 on v4-in-v6 tunnel causes v6 
fragmentation on the v6-in-v6 tunnel for the packets whose size is 
greater than 1240 bytes.

On the other hand, there have been comments on the contrary, that 
mismatching MTU/MRU is a bad thing, like pointed out by itojun.  I 
remember the message but have been unable to find the message referred 
to in:

http://ops.ietf.org/lists/v6ops/v6ops.2003/msg01718.html

Now, I'd like to move on here.  I personally don't see much of a
problem with mismatching MRU/MTU values as long as they are below
1500.  But I'd like to see whether there are any evidence indicating
otherwise.

In Dave's scenario, the obvious easy fix is to use dynamic MTU 
determination instead of the static one, but this avoids the real 
question of when it would be OK to raise the MTU w/ static MTU 
configuration.

Moreover, I believe the static MTU case must also be able to react to
the received ICMPv6 packet too big messages (e.g., you configure the
interface to e.g. 1500, but someone sends you a message that 1280 is
the maximum -- do you have to react to it?  I assume yes, but I guess
someone would view that this "very minimal v6 PMTU detection
mechanism"  would be out of scope.

So, to sum my questions here, asking for feedback:

 - do you have references/evidence of the problems caused by 
   mismatching MTU/MRU that should be considered here?

 - MUST a static tunnel MTU case also implement an algorithm to
   react to the received ICMPv6 Packet too Big messages, e.g. to lower 
   the MTU?  (or is this really a subset of dynamic tunnel MTU).  
   RFC2463 sect 3.2 seems to give an impression that this would have
   to be done, but not sure.

 - if people agree with this MUST, and no MTU/MRU strong mismatch 
   evidence is found, I believe the "MUST default to 1280" might be 
   too strong -- the worst that could happen is to a) create a 
   blackhole if a router is able to forward a packet but the 
   on-link recipient not receive it, b) if too high value is picked,
   v4 fragmentation would ensue (bad).

 - do you think it would be OK to recommend dynamic MTU instead in the 
   double encapsulation scenario described by Dave?

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