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

["Dave Thaler" <dthaler@windows.microsoft.com>]

This is the issue I mentioned again in Minneapolis...

From draft-ietf-v6ops-mech-v2-01.txt:
> 
> 3.2.1.  Static Tunnel MTU
> 
>    A node using a static tunnel MTU MUST limit the size of the IPv6
>    packets it tunnels to 1280 bytes i.e., treat the tunnel interface
as
>    having a fixed interface MTU of 1280 bytes.  An implementation MAY
>    have a configuration knob which can be used to set a larger value
of
>    the tunnel MTU than 1280 bytes, but if so the default MUST be 1280
>    bytes.  A larger fixed MTU should not be configured unless it has
>    been administratively ensured that the decapsulator can reassemble
>    packets of that size.  Care should be taken when manually
configuring
>    large tunnel MTUs to only do so when the MTU of the IPv4 path to
the
>    tunnel endpoint is large to avoid causing excessive fragmentation.

Here's a scenario which may become common:

A mobile node has
1) an Ethernet interface connected to a v4-only network
2) some type of IPv6 over IPv4 tunnel that follows this spec,
    where the IPv4 address used for encapsulation is the address 
    on interface 1.
3) an IPv6 over IPv6 tunnel to its home agent to support mobile IPv6,
    where the IPv6 address used for encapsulation (i.e. its
care-of-address)
    is the IPv6 address on interface 2.  With route optimization
optional, 
    one common case is where the majority of communication would be over

    this interface (reverse tunneled).

Interface 3's MTU can be no smaller than 1280, so let's assume it's
1280.
If interface 2's MTU is 1280, then each 1280-byte packet being
reverse-tunneled out interface 3 must undergo fragmentation after being 
encapsulated to go out interface 2.  As a result, excessive
fragmentation 
on most data packets results.

If the mobile node changes the MTU of interface 2 to be some larger
value,
then gratuitous fragmentation can be avoided.  Obviously if the IPv4
path MTU isn't large enough to support 1280 + both encapsulations you'll

get fragmentation regardless.  But in general the mobile node doesn't
know ahead of time whether a larger MTU will cause fragmentation
whereas it does know that using 1280 WILL cause fragmentation.

The current text is ambiguous as to whether it would be legal or
illegal for the mobile node to (say) use a larger MTU on interface 2 
(with IPv4 DF bit clear) automatically upon being configured to be a 
mobile node.  Is the intent that this is illegal?  If so, this 
seems harmful, and it would be good to point out that excessive 
fragmentation will occur for mobile nodes.  If this is not the 
intent, then the language should be clarified.

Also on the sentence:
> A larger fixed MTU should not be configured unless it has
> been administratively ensured that the decapsulator can reassemble
> packets of that size.

RFC 2460 section 5 says:
>  A node must be able to accept a fragmented packet that, after
>  reassembly, is as large as 1500 octets.

Is this statement sufficient "administrative assurance" that the 
decapsulator can reassemble packets up to 1500 octets in size?

If so, I'd propose rewording as:
> A fixed MTU larger than 1500 bytes should not be configured unless it
has
> been administratively ensured that the decapsulator can reassemble
> packets of that size.

-Dave