mech-v2: Decapsulation/MRU requirements and Static MTU changes?

[Pekka Savola <pekkas@netcore.fi>]

Hi,

I'm trying to find a proper way to ensure that the decapsulation and
Static MTU change rules appropriate.  I'm Cc:ing itojun in particular,
as he has been the strongest proponent of "only 1280 for static MTU
case".

Would there be objections to changing the decapsulation and static MTU 
rules as follows:

 1) all decapsulators MUST be capable of reassembling an IPv4 packet
up to the maximum of _1300_ bytes, the largest (IPv4) interface MTU on
the decapsulator, _and 1500 bytes_.

(changes highlighted with _underline_; in practice this would add no
new practical requirements but could simplify certain assumptions; I 
raised 1280 bytes to 1300 because we must allow 1280+20 bytes.) 

 2) all decapsulators MUST be capable of having an IPv6 Maximum 
Receive Unit (MRU) of at least the maximum of of 1280 bytes,  the 
largest (IPv6) interface MTU on the decapsulator, and 1500 bytes.

(in practice, I don't think this adds any more requirement which would
not exist today.  Even though one would set MTU=1280, you still have
to be able to receive the packets up to the physical MTU of the
interface anyway.  There was some discussion of MRU in the past, and I
believe there was something close to rough consensus to require even
MRU of 4400 bytes, but it was not added for other reasons.)

 3) A node using a static tunnel MTU MUST treat the tunnel interface as
   having a fixed interface MTU.  By default, the MTU MUST be between
   1280 and 1480 bytes (inclusive), but it SHOULD be 1280 bytes.  In
   case the default is not 1280 bytes, the implementation MUST have
   a configuration knob which can be used to change the MTU value.

(This may be objectionable -- but my point is, with the above two
1)-2) clarifications, there would not be an interoperability problem
with setting an interface MTU to be higher than 1280 by default, as
long as it's not "too high".  I'm tempted to make this change, as a
large number of implementations are just doing static MTU, and IMHO
static MTU=1280 seems to hurt more than it helps -- and there is only
about one implementation I know of which actually adheres to this
"1280 bytes" rule (the most common is 1480 I think))

(Additionally, there would be some text describing the applicability 
and the problems of certain scenarios.)

Even if there would be objections to 3), I think adding 1) and 2)  
would still make sense to ensure maximal interoperability.

The alternative to the change 3) would be leaving the text as is,
describing the problems it causes at a bit more length, and live with
the disparity of the spec and the implementations.

(co-chair hat on) yes, there will be a 1 week last call when done, but 
trying to get some measure of consensus on the changes will likely 
avoid unnecessary churn (hat off).

Thoughts?

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