Subject: RE: [nemo] Fragmentation at mobile router

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 3 Apr 2006 10:58:51 -0700

> Thanks for comments.
> 
> 
> 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.

sounds good to me.

Vijay

> 
> 
> 
> Best Regards
> Takaaki Moriya
> [email-masked]
> 
> 
> 
> On Fri, 31 Mar 2006 10:40:25 -0800
> "Vijay Devarapalli" <[email-masked]> wrote:
> 
> > > I have a question about fragmentation at mobile router.
> > > When mobile router receives a long packet from a node in 
> the mobile
> > > network, should mobile router fragment this packet?
> > 
> > I would prefer the mobile router to tell the
> > MNN to reduce MTU.
> > 
> > > Of course, normally it is end node to manage fragmentation after
> > > receiving ICMP. However, if so, when the mobile network 
> > > moves, MTU size
> > > toward tunneling path may be changed and then end nodes 
> in the mobile
> > > network receive ICMP packet too big.
> > > (e.g. when mobile router moves under another mobile router, 
> > > MTU size is
> > > changed.)
> > > It means that movement forses end node to retransmit the 
> > > packet. It goes
> > > against the rule of hiding movement from end node. 
> > 
> > receiving ICMP packet too is not the same as
> > the MNN being aware of the movement.
> > 
> > Vijay
> > 
> > > 
> > > 
> > > The problem in mobile router is the same in home agent.
> > > 
> > > 
> > > Thanks in advance.
> > > 
> > > ---
> > > Best Regards
> > > Takaaki Moriya
> > > <[email-masked]>
> > > 
> > > 
> > > 
> 
> ---
> 
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 4 Apr 2006 10:27:52 -0700

what Pascal wrote makes sense to me. couldn't
have described it better.

Vijay 

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
> Sent: Tuesday, April 04, 2006 2:01 AM
> To: Keiichi SHIMA; [email-masked]
> Cc: [email-masked]; Vijay Devarapalli
> Subject: RE: [nemo] Fragmentation at mobile router
> 
> Hi Keiichi
> 
> 
> fragmentation
> at
> >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]>
> 
>