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

[Alexandru Petrescu <alexandru.petrescu at gmail.com>]

Keiichi SHIMA wrote:
> Hi,
>
> On 2007/03/26, at 22:00, Alexandru Petrescu wrote:
>
> > But should be done in tandem with that 'F' flag by HA.  One wouldnt
> >  want the MN to request eg UDP encapsulation and the HA to force IP
> >  encapsulation.
>
> I think there is no such flag to force IP-in-IP encapsulation in the 
> current text.  The only specified flag is to force the IP-in-UDP 
> encapsulation flag, if I read the spec correctly.  So I think we 
> don't need to worry about the above case you pointed out.

I think that's right, 'F' flag forces UDP encapsulation, and I'm not
aware of a flag to force IP-in-IP encapsulation.

Remark there's an incoherency between rfc3519 and DS-MIPv6 with respect
to who sets that 'F' flag.  RFC3519 says MN sets it while DS-MIPv6 says
HA sets it.

rfc3519:
> 3.1 UDP Tunnel Request Extension
>
> F                   F (Force) flag.  Indicates that the mobile node
> wants to force MIP UDP tunnelling to be established.

DS-MIPv6:
> If no NAT device was detected in the path between the mobile node and
>  the home agent then IPv6 packets are tunneled in an IPv4 header, 
> unless the home agent forces UDP encapsulation using the F flag.



> > I prefer the MN to decide which encapsulation method to use (and 
> > not the HA).  However, the HA is the first to know whether there's 
> > a NAT in between.  A MN doesn't know whether there's a NAT in 
> > between, at the time it sends BU.
>
> The protocol I expect is as follows.
>
>
> Pattern 1) when MN doesn't have any preference
>
> 1-1) MN send a BU without any flag
>
> 1-2) HA receives the BU and checks if UDP encapsulation is necessary 
> or not
>
> 1-3a) If UDP is necessary, the HA replies with a BA with the 'F' flag
>  to force the MN to use UDP encapsulation
>
> 1-3b) If UDP is not necessary, the HA replies with a BA without any 
> flag, that results in using IP-in-IP encapsulation

Ok.

> Pattern 2) when MN has UDP tunnel preference
>
> 2-1) MN sends a BU message with the newly defined flag (let's call it
>  as the 'U' flag).
>
> 2-2) HA receives the BU and replies with a BA message with the 'F' 
> flag to force UDP encapsulation, because the MN has requested UDP 
> encapsulation mode.  There is no need to detect NATs.  The HA simply 
> use UDP because the MN requests it.

Ok.

> The pattern 1 is the behavior specified in the current specification.
>  That is, the default tunneling mechanism is IP-in-IP, but UDP 
> encapsulation is used when the HA detects its necessity.  All 
> implementors can implement this way.
>
> The pattern 2 is a new action introduced by the new flag.  This 
> allows the MN to prefer the UDP encapsulation mode, with minimum spec
>  changes. What the HA need to do is simply to check the new flag
> (say, 'U' flag), and to reply with a BA message with the 'F' flag if
> an incoming BU message contains the 'U' flag.

Yes, provided we're clear of that 'F' flag.  As mentioned above, its
definition and use is different between rfc3519 and DS-MIPv6.

> > I've always thought there should be some form of tunnelling 
> > parameters negotiation between MN and HA, before sending the 
> > BU/BAck.  Also periodic heartbeats with re-negotiation if 
> > necessary.
>
> I'm not sure what kind of tunneling parameters you are thinking 
> about, but I prefer to reduce the number of tunneling mechanisms.

Yes, I prefer to reduce the number of tunnelling mechanisms too.

If the UDP encapsulation is implemented as a virtual tunnel interface 
then that interface needs to have an IPv4 address on it.  That IPv4 
address can be the IPv4 address assigned on the real interface.  But 
this leads to having same IP address on two interfaces.  I think this is 
not good.

> I want to provide less number of tunneling mechanisms, rather than to
>  provide freedom to choose a tunneling mechanism from a number of 
> various tunneling mechanisms.  It may make implementors confusing and
>  may make interoperability more difficult.

I think a first implementation that prefers UDP for data encapsulation 
and signalling is a good idea.

Alex


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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