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

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

Hello Hesham,

Since the consensus call ends Tuesday, maybe this is my last chance  
to make myself clear.

On 2007/03/30, at 19:15, Hesham Soliman wrote:

>>> => Yes there is, I explained it during our discussion and on the
>>> mailing
>>> list. Others also explained it on the list. I'm attaching
>> one of my
>>> emails
>>> again. The idea that you can only support one tunnelling protocol
>>> is *not*
>>> technically possible as you request it. Please read my email
>>> attached again.
>>
>> I think you are explaining the reason why we can allow IP-in-IP
>> tunnel mode.  I have never said to disallow IP-in-IP mode.  Your
>> implementation can still use both IP-in-IP, IP-in-UDP of course.
>>
>> What I was asking was the technical reason why you want to
>> reject UDP
>> tunnel only mode.
>
> => I'm not sure how those two conclusions were made. Your initial  
> suggestion
> was to
> remove IP in IP,

Yes.

> which we won't go over again, now your own compromise
> approach was to allow the MN to request UDP only.

Yes.

> I'm not sure what I'm
> allowing or disallowing but this is a WG concensus call.

I requested the possibility to operate DSMPv6 with UDP tunnel mode  
only to allow a mobile node that implements UDP tunnel mode only.   
However, the option A in your mail for consensus call said that the  
HA can reply the mobile node with a BA message to indicating IP  
tunnel mode.  This is the point I don't understand whether my idea is  
understood correctly or not.

>> As I said, introducing the 'U' flag (or in other words,
>> RFC3519 style
>> 'F' flag) allows some limited implementation (UDP only
>> implementation).  Such implementations are still interoperable with
>> full (both IP tunnel and UDP tunnel) implementations.
>
> => Quoting your comments to Henrik:
>   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'.
>
> If you want option A to suggest that the HA rejects the BU instead of
> Accepting it and telling the MN to use IP in IP, I don't have an  
> opinion on
> that. But neither this modification, nor option A as I sent it  
> before will
> guarantee that the MN will always use UDP *only* because they both  
> depend on
> the HA's acceptance. So what is it that you are suggesting we do?  
> and why?

OK, let me explain what is the difference between the above two cases.

case 1)
- assumption
   - MN operates UDP tunnel mode
   - HA decides tunneling mode (UDP or IP)
- operation case 1
   1-1. MN sends a BU with the 'U' flag.
   1-2. HA returns a BA by accepting the 'U' flag.
   1-3. DSMIPv6 is operated with UDP tunnel.
- operation case 2
   2-1. MN sends a BU with the 'U' flag.
   2-2. HA returns a BA by suggesting IP tunnel mode.
   2-3. MN stops its operation.
        The BC entry is left because the HA cannot know
        that MN has stopped its operation.

case 2)
- assumption
   - MN operates UDP tunnel mode
   - HA decides accepts or rejects its request
- operation case 1
   1-1. MN sends a BU with the 'U' flag.
   1-2. HA returns a BA by accepting the 'U' flag.
   1-3. DSMIPv6 is operated with UDP tunnel.
- operation case 2
   2-1. MN sends a BU with the 'U' flag.
   2-2. HA returns a BA with error code.
   2-3. MN stops its operation.
        HA stops its operation for the MN.

The difference between case 1 and 2 is that, in the case 1, the  
unnecessary BC entry is left for a while.

>> I simply don't understand why we cannot allow such implementation.
>
> => Please explain how your suggestion above makes any difference to  
> the MN.

I hope I could explain the difference in the above paragraph...

> If the MN only implements UDP then in both cases (whether the BU is  
> rejected
> or the HA forces IP in IP) the MN will not be able to communicate  
> with the
> HA. Please explain clearly what you're trying to do.

No the MN cannot communicate with the HA if UDP tunnel request is  
rejected.

But I think there is difference in the ways of how to reject the  
request.  Your proposal is 'reject UDP tunnel mode and suggest IP  
tunnel mode.'  My proposal is 'reject the UDP tunnel mode and reject  
the binding message.'

Since we are talking about the implementation that provides UDP  
tunnel only mode, the former is not useful.

> I think there is an
> issue with trying to fit the standard around a particular  
> implementation
> here....

I'm not sure I was asked a question or not in the above sentence...

Anyway, I think the issue here is if we allow a limited operation  
scenario (UDP tunnel mode only) or not.   The option A, you proposed  
in the initial consensus call mail, may allow the operation, but as I  
explained in the above message, I think it is better to simply accept  
or reject the MN's UDP tunnel request rather than asking the MN to  
use IP tunnel mode.

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: "Hesham Soliman" <[email-masked]>
Date: Tue, 3 Apr 2007 15:07:59 +1000

> unnecessary BC entry is left for a while.

=> Right, in another words, there is no difference for the MN and in both
cases it can't get connectivity. I have no problems with rejecting the BU
instead of replying with an error code, this is a side issue. My point is
that this has no bearing on whether UDP only is used because all cases will
lead to no connectivity if the HA doesn't accept the request.

Hesham