Subject: RE: [nemo] Fragmentation at mobile router

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 4 Apr 2006 11:01:25 +0200

Hi Keiichi

>> Since RFC3963 does not refer to this issue, it seems to be outside of
>> the scope of NEMO specification.
>> Can we conclude it's implementation-dependent ?
>> If so, TAHI interoperability guideline will not specify fragmentation
at
>> mobile router as well as sending ICMP packet too big by mobile
router.
>
>Let me ask a clarification question.

[Pascal] I'll describe what our implementation does. Now, I think it is
more a matter of good sense than something that could vary a lot with
implementations. In any case, the MR must do something so that the
packets go through, don't you think?

>
>A mobile router have to send an ICMP too big, if the forwarded packet
>exceeds the MTU of the tunnel interface between the MR and its HA.
>Otherwise, we lose connectivity.
>
[Pascal] The MR can not fragment the packet that it will tunnel when it
forwards it over the tunnel interface; but it can fragment the packet
once it has been tunneled, because at this point, the MR IS the source
of the MR to HA packet, so the rules are not broken. The HA reassembles
the tunneled packet, receives it, and then it extracts the inner packet
(MNN to CN) which does not have a fragment header.

>A mobile router may not send a too big message if the packet is bigger
>than the physical path MTU (not the MTU for the tunnel i/f).  It is
>implementation dependent.
>
[Pascal] For the MR, the tunnel is just another interface, with an MTU
that it can compute based on the encapsulation overhead and packet too
big it would receive because of recent history on MR to HA packets. The
MR needs to reassess that MTU every so often and when it moves. If the
MR does not send packet too big to the MNN, then it will have to
fragment the encapsulated packets forever. 

It makes sense to notify the MNN, unless the tunnel MTU gets below the
min MTU of 1280 bytes. In a heavy case of nested NEMO, such a thing
could happen.

>Do I understand correctly?
>
>BTW, is there any word about the MTU between an MN/MR and an HA?  Our
>implementation uses the IPv6 minimum MTU (1280) for the interface, but
>I know some implementations use bigger MTU size, which may cause a
>Path MTU discovery problem.
>
[Pascal] Initially, we set the tunnel MTU to (egressMTU-overhead), and
then react on packet too big that we might receive because of MR to HA
packets. By default, egressMTU will be 1500 on Ethernet. If you force
the tunnel MTU to 1280 from the start, then nested NEMO might be a
problem for you.

>---
>Keiichi SHIMA
>IIJ Research Laboratory <[email-masked]>
>WIDE Project <[email-masked]>

---

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 04 Apr 2006 20:04:05 +0900 (JST)

Hi Pascal,

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Subject: RE: [nemo] Fragmentation at mobile router
Date: Tue, 4 Apr 2006 11:01:25 +0200

> (MNN to CN) which does not have a fragment header.

OK, our implementation does the same as yours.

> fragment the encapsulated packets forever. 

I understand.  But it is a nature of a tunnel interface, isn't it?
Usually, a node which has an IPv6-over-IPv6 tunnel interface just
notify the MTU size of the tunnel interface itself when forwarding
packets.  The node doesn't notify the MTU value of the inner path.
 
> the tunnel MTU to 1280 from the start, then nested NEMO might be a

I think the problem is there is no specification how to decide the
tunnel MTU size between an MN and an HA.  I guess your HA may have
interoperability problem with an MN which assumes the tunnel MTU as
1280.  Since you may send a packet which size is 1500, but the tunnel
i/f of the MN may drop it because it exceeds the MTU size.  In this
case a packet too big will not be generated, since it is generated
when packet is being sent to an interface, not being received from an
interface.

If I remember correctly, the very old Mobile IPv6 specification was
talking the MTU size of the tunnel interface, I think.  But the latest
specification doesn't say anything.  Do we need to clarify the point
in another document?

Regards,
---
Keiichi SHIMA