Re: [Mip6] [issue94] fixing encapsulation mechanism in IPv4 network

[Keiichi SHIMA <keiichi at iijlab.net>]

Hello Hesham,

On 2007/03/21, at 19:40, Hesham Soliman wrote:

> > > switching between the UDP tunnel and IP n IP is very small (from an
> > > implementation point of view).
> >
> > I may not agree on the above point.  Since UDP is a transport
> > protocol, encapsulating something in it cannot be handled by a
> > *normal* packet decapsulation flow, while IPv4-in-IPv4 can
> > be fit to
> > the natural flow.  So switching from IPv4 encapsulation to UDP
> > encapsulation may not be so easy as you say, especially for MIP
> > stacks that are implemented in user space.
>
> => I'm not sure I get that. If you're implementing in user space  
> you would
> still know how to handle IP n IP today because that's what MIP6  
> does today
> and some people have already done that in user space. The UDP part  
> is always
> there because the BU is always sent on UDP. So if someone already  
> implements
> MIP6 in user space they already need to know how to handle IP n IP  
> and if we
> choose to do UDP only in DSMIP then they end up in a situation  
> where they
> have to handle both tunnelling mechanisms anyway.
>
> So to summarise for the user space case:
>
> - You always need to handle IP n IP for native MIPv6 (it doesn't  
> matter
> whether it's v6 in v6 or v6 in v4, it's all IP n IP).
>
> - You always need to handle the UDP tunnel because the BU in DSMIP  
> is always
> sent in UDP.
>
> The difference in the DSMIP case is that normal traffic can also be
> tunnelled in UDP, but that's the case you want to keep anyway. So  
> you'll
> always end up having to support both types of tunnels whether we  
> remove IP n
> IP from DSMIP or not.
>
> What am I missing?

What I wanted to remove is the switching mechanism of encapsulation  
format when a mobile node is in the IPv4 network.  Currently, our  
implementation does not support IPv* in IPv4 encapsulation mechanism  
because of course MIPv6 doesn't require that.  If we a mobile node is  
allowed to use only the UDPv4 encapsulation mechanism, then we wanted  
to implement that.

But, as Romain said in other mail, at least it seems easy to  
implement both IPv4-encap and UDPv4-encap and switching between them  
in Linux.  So it depends on the design of implementation.


So, I want to propose a compromise.  Isn't it possible to add a flag  
for a mobile node to declare that the node wants to use the UDPv4  
encapsulation mechanism when sending a binding update message to its  
home agent?   Hesham said to me in our local conversation yesterday,  
such a flag already exists in the current spec, however, I re-read  
the text and couldn't find such a flag.

There is the 'F' flag to force the UDP encap format, but it is for a  
home agent and not for a mobile node.   In the current spec, a mobile  
node doesn't have any freedom to choose the encapsulation mechanism,  
only HA can force a mobile node to use UDP encapsulation.

If a mobile node can have such a flag, then nodes that want to use  
IPv*-in-IPv4 format can still keep the current encapsulation  
mechanisms (that is, IPv*-in-IPv4 by default and switch to UDPv4  
whenever necessary), and nodes that want to support only UDPv4  
encapsulation can specify its request in a binding update message  
using the newly added flag.

Is it feasible?

We (Koshiro Mitsuya, one of the developers of our MIPv6  
implementation) will send proposed text mentioning the above  
mechanism later.

---
Keiichi SHIMA
IIJ Research Laboratory <keiichi at iijlab.net>
WIDE Project <shima at wide.ad.jp>




_______________________________________________
Mip6 mailing list
Mip6 at ietf.org
https://www1.ietf.org/mailman/listinfo/mip6