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

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 3 Apr 2007 13:58:25 +0900

Hello Henrik,

On 2007/03/30, at 20:26, Henrik Levkowetz wrote:

>> The 'F' flag in RFC3519 is a flag sent from a mobile node to request
>> its home agent to use UDP tunneling mode.  If the home agent
>> understand the RFC3519 'F' flag, then it either 'accepts the UDP
>> tunnel' or 'rejects the binding update'.
>>
>> Is my understanding correct?
>
> Seems so, yes.  But as it also says in the text, if the HA knows
> how to do UDP tunnelling, it SHOULD accept it, unless it has been
> administratively prohibited (configured to not use it).

OK.  I agree with the above operation and hope DSMIPv6 allows this  
kind of operation.

>> I think the action is different from the Hesham's proposal.  His
>> proposal allows to override the RFC3519 style 'F' flag at the HA.
>> Thus, the HA may accept the BU message with the RFC3519 style 'F'
>> flag even the HA doesn't allow UDP tunnel.  Since the mobile node is
>> forcing UDP tunnel, replying with a BA message requesting not to use
>> UDP is not correct way I think.  (Rejecting the request is
>> understandable as described in RFC3519)
>>
>> So let me rephrase the option A.
>>
>> A. Add a flag that allows the MN to request UDP tunnelling interface
>> (independently of the presence of a NAT) from the HA, when sending
>> the BU.  If the HA accepts the request then the HA replies the BU
>> with a BA with the 'F (Force UDP)' flag.  Otherwise the HA rejects
>> the BU with status code "administratively prohibited".
>
> This is the understanding I already had of the meaning of Hesham's
> proposal A.
>
> I don't however, understand why we have to use different flag logic
> in MIPv4 and MIPv6 -- why not let the BU have a 'Force' flag and the
> BA be flag-less and either accept or reject the BU?

Because the HA may want to suggest UDP tunneling mode, in case that  
the MN doesn't specify its tunnel mode preference.

If the MN supports both IP tunnel and UDP tunnel mode, the MN will  
not set the flag.  If the HA detects necessity of UDP tunneling in  
this case, it needs a method to notify the MN of using UDP tunnel  
mode.  This is my understanding.

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

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 03 Apr 2007 09:48:59 +0200

Hi Keiichi,

on 2007-04-03 06:58 Keiichi SHIMA said the following:
[snip]

> mode.  This is my understanding.

This doesn't make sense to me.  If the MN can manage to get through
to the HA, I don't see any reason why the HA should specify tunnelling
-- only in cases where there is trouble getting a BU through to the
HA without tunnelling does tunnelling make sense, no?  So this has to
start at the MN end.

	Henrik

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 3 Apr 2007 20:37:27 +0900

Hi

I prefer A, but i want one clarification.

When a HA receives a BU setting the flag, how it can override the flag?
I want to know whether HA just accepts the BU or not.

As keiichi mentioned, if mobile nodes supporting only UDP-tunnel are  
available,
It will be a problem if HA simply accepts the BU and overrides it by BA.

Even if the BU is accepted, the MN cannot establish a tunnel with the  
HA.
The HA will keep the garbage binding status during the active  
lifetime if the MN just gives up IP-in-IP.

The HA should rejects the BU and notifies its preference to the MN by  
the BA.
The MN can re-try the new BU with the HA.
MN should accept this burden since it requests the preference to the HA.

regards,
ryuji

On 2007/03/28, at 19:32, Vijay Devarapalli wrote:

> Keiichi SHIMA wrote:
>> Hello Hesham,
>> I think the text explaining the option 'A' is not exactly what I  
>> proposed in my previous mail.  Please let me clarify the text  
>> about the option 'A'.
>> On 2007/03/28, at 16:33, Hesham Soliman wrote:
>>> (independently of the presence of a NAT) from the HA, when  
>>> sending the BU.
>>> The HA can override the MN's request. Or,
>> The idea is to introduce a new flag for MN to request the UDP  
>> tunnel mode.  Let's call it as the 'U (requesting UDP tunnel)'  
>> flag.  If the MN doesn't specify the 'U' flag, the behavior is  
>> exactly the same as the current specification.  The HA can decide  
>> what kind of tunneling mechanism (IP-in-IP or UDP-in-IP).
>> When the MN sets the 'U' flag on, the HA always replies with the  
>> 'F (Force UDP tunnel)' flag.  This is a new behavior what I want  
>> to propose.
>
> We would also need to mention when the MN would be setting this
> flag. Is it when it wants to use UDP encapsulation due to
> implementation related considerations? I guess you want to use
> the 'U' flag for this.
>
> But there are others who have expressed that this flag can be
> used for firewall traversal. Since the MN wouldn't know if
> there is a  firewall on the path, it would end up setting the
> 'U' flag all the time. If the HA can't override it, then
> providing a NAT detection mechanism is useless, IMO.

> Vijay
>
>> The HA shouldn't override the 'U' flag.  If we allow overriding  
>> the 'U' flag, then there is no difference between the option 'A'  
>> and 'B'.
>> Regards,
>> ---
>> Keiichi SHIMA