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

[Keiichi SHIMA <keiichi at iijlab.net>]

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 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


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.


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.



> 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.  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.

Regards,
---
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