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

From: Keiichi SHIMA <[email-masked]>
Date: Wed, 28 Mar 2007 19:06:37 +0900

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:

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

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
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: Wed, 28 Mar 2007 20:13:03 +1000

> 'U' flag, then there is no difference between the option 'A' and 'B'.

=> There is a difference between A and B of course. The difference is that
in B the MN can't request anything and is either told to use UDP or told to
use IP in IP. In A, the MN can request UDP tunnels. Like any other request
in MIPv6 (e.g. BU lifetime, HoA ....etc) the HA always has the upper hand
and decides whether the request is acceptable or not. I simply followed the
same rule here. For instance, the HA/MAP might think UDP tunnelling is not
acceptable for policy reasons (e.g. an operator doesn't want the MN to waste
BW when UDP is not needed). I don't have an exhaustive list of scenarios so
I just erred on the conservative side of keeping with the current approach
in MIPv6. 

Hesham

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 28 Mar 2007 05:29:49 -0500

All,

Sorry for jumping in without previously being involved in the
discussion. However, in my mind, HA should have the upper hand of
deciding whatever the MN is requesting. If the HA has the right to
reject MN BU, it has the right to deny UDP encapsulation.

I believe that should be the correct approach.

Regards,
Ahmad

> -----Original Message-----
> From: Keiichi SHIMA [mailto:[email-masked]] 
> Sent: Wednesday, March 28, 2007 6:07 AM
> To: Hesham Soliman
> Cc: [email-masked]; Keiichi SHIMA
> Subject: [Mip6] Re: concensus on [issue94] fixing 
> encapsulation mechanism in IPv4 network
> 
> 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'.
> 
> 
> > (independently of the presence of a NAT) from the HA, when 
> sending the 
> > BU.
> 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.
> 
> 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
> IIJ Research Laboratory <[email-masked]> WIDE Project 
> <[email-masked]>
> 
> 
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 28 Mar 2007 03:32:40 -0700

Keiichi SHIMA wrote:
> proposed in my previous mail.  Please let me clarify the text about the 
> option 'A'.
> 
> 
>> (independently of the presence of a NAT) from the HA, when sending the 
>> BU.
> 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 
> (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

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Mar 2007 18:53:33 +0200

> 'U' flag, then there is no difference between the option 'A' and 'B'.

Umm.  

I hope we're not in "Not Invented Here" mode.

Is there any reason to deviate from the specification of this flag,
and the way the HA handles it, which is given in the MIPv4 NAT traversal
specification?

See http://tools.ietf.org/html/rfc3519#section-3.1.1

	Henrik

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 29 Mar 2007 14:16:25 +0900

Hello,

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

>> proposed in my previous mail.  Please let me clarify the text  
>> about the option 'A'.
>>> sending the BU.
>> 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.
>

I think my idea was not well explained...  (or I am missing  
something...)

If a mobile node doesn't know anything about NAT nor FW, and if the  
mobile node supports both IP-in-IP mode and IP-in-UDP mode, then the  
node doesn't need to specify the 'U' flag.  In that case, the HA will  
decide whether the IP-in-UDP mode is necessary or not, and replies  
with a BA message with the 'F' flag if needed.  There is no need to  
put the 'U' flag for mobile nodes that supports both encapsulation  
modes.

What I wanted to add was the support for mobile nodes that wanted  
simpler (I mean, supporting only IP-in-UDP mode) implementation.   
Only such nodes will set the 'U' flag.

Hope I could make myself clear...

---
Keiichi SHIMA

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 29 Mar 2007 15:25:46 +1000

> Hope I could make myself clear...

=> I know that's what you originally wanted but you then asked for this
compromise approach. There was (and still is) a lot of resistance to the
rationale you suggested, which is to reduce the implementer's work in favour
of always using one tunnelling mechanism. The logic behind it is not really
acceptable, so we can settle for this approach, under the assumption that
the HA should accept the MN's request unless there is a reason (i.e. it is
configured) for not accepting it. Mandating one tunnelling approach is just
not a good idea.It's not supported technically (as I mentioned before you
have to support both in all cases) or by previous specs. 

Hesham

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 29 Mar 2007 14:41:20 +0900

Hello,

> use IP in IP. In A, the MN can request UDP tunnels. Like any other  

I don't understand if there is any meaning to allow a mobile node to  
request UDP encap when the HA can ignore the request...  (maybe I'm  
missing something?)

> and decides whether the request is acceptable or not. I simply  

These are OK because even the HA rejects the MN's request. e.g. when  
the MN request 1000 seconds lifetime, but the HA allows 100 seconds,  
there is no interoperability problem here.  Because the MN can work  
with 100 seconds lifetime in this case.

> I just erred on the conservative side of keeping with the current  

As I talked to you at the last IETF, my intension is to allow mobile  
nodes that implement only the UDP tunnel mode for v4 traversal  
purpose.  Since such nodes don't decapsulate IPvX-in-IPv4 packets for  
DS-MIPv6, replying with a BA message rejecting UDP encapsulation and  
forcing IPvX-in-IPv4 mode doesn't work.

I think you are implicitly assuming IPvX-in-IPv4 is a must feature.   
So you only allow MN and HA that support both IPvX-in-IPv4 and IPvx- 
in-UDPv4 modes.  But I think we can also allow UDP only operation.   
There is no technical reason to reject the possibility, is it?  If we  
can introduce the flag (the 'U' flag from the MN), then we can allow  
HA and MN that only support the UDP tunnel mode keeping  
interoperability between all of them.  There are 4 cases:

HA (UDP mode, IP mode) - MN (UDP mode, IP mode)
   => works as specified in the current spec

HA (UDP mode) - MN (UDP mode, IP mode)
   => HA always replies with the 'F' flag and works with UDP mode

HA (UDP mode, IP mode) - MN (UDP mode)
   => MN always sets the 'U' flag and works with UDP mode

HA (UDP mode) - MN (UDP mode)
   => MN always sets the 'U' flag and works with UDP mode

There is no drawback, I think.

Regards,
---
Keiichi SHIMA

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 29 Mar 2007 14:44:26 +0900

Hello,

> I believe that should be the correct approach.

Yes, as long as both nodes have the same features.

But I am now talking about a mobile node that only supports the UDP  
tunnel mode.  In this case, forcing the IP-in-IP tunnel mode by the  
HA has no meaning because the MN doesn't support the mode.

Regards,
---
Keiichi SHIMA

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 29 Mar 2007 15:51:17 +1000

> There is no technical reason to reject the possibility, is 
 > it?  

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

Hesham 

If we  
 > WIDE Project <[email-masked]>

Subject: RE: [Mip6] [issue94] fixing encapsulation mechanism in IPv4 network
From: "Hesham Soliman" <[email-masked]>
To: "'Keiichi SHIMA'" <[email-masked]>
Cc: "'Mip6 issue tracker'" <[email-masked]>, <[email-masked]>
Date: Wed, 21 Mar 2007 20:40:16 +1000

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

Hesham

---

From: Keiichi SHIMA <[email-masked]>
Date: Fri, 30 Mar 2007 18:22:03 +0900

Hello Henrik,

> See http://tools.ietf.org/html/rfc3519#section-3.1.1

I'm not sure I understand the 'F' flag defined in RFC3519, but let me  
clarify my understanding.

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?

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

Does it make sense?

---
Keiichi SHIMA

---

From: Keiichi SHIMA <[email-masked]>
Date: Fri, 30 Mar 2007 18:32:31 +0900

Hello Hesham,

> technically possible as you request it. Please read my email  

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.

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.

I simply don't understand why we cannot allow such implementation.   
I'm proposing to keep the current functions completely, and  
requesting to allow some limited implementation which is still  
interoperable.

Regards,
---
Keiichi SHIMA

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 30 Mar 2007 20:15:50 +1000

> > list. Others also explained it on the list. I'm attaching 
 > one of my  
 > > emails

=> I'm not sure how those two conclusions were made. Your initial suggestion
was to
remove IP in IP, which we won't go over again, now your own compromise
approach was to allow the MN to request UDP only. I'm not sure what I'm
allowing or disallowing but this is a WG concensus call. 

 > full (both IP tunnel and UDP tunnel) implementations.

=> Quoting your comments to Henrik:

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? 

 > I simply don't understand why we cannot allow such implementation.   

=> Please explain how your suggestion above makes any difference to the MN.
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. I think there is an
issue with trying to fit the standard around a particular implementation
here....

Hesham

 > requesting to allow some limited implementation which is still  

=>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 30 Mar 2007 13:26:25 +0200

Hi Keiichi,

> Hello Henrik,
...
> 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).

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

	Henrik

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 30 Mar 2007 15:12:57 -0500

Hi Keiichi,

> HA has no meaning because the MN doesn't support the mode.

Only supporting "UDP tunnel mode" by the MN is not an acceptable option.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 30 Mar 2007 15:28:09 -0500

Hi Keiichi,

> implementation can still use both IP-in-IP, IP-in-UDP of course.

Okay... So you agree that depending on the scenario you could use either
IP-in-IP or IP-in-UDP, right?

> What I was asking was the technical reason why you want to reject UDP

UDP tunnel only mode is less optimal than IP-in-IP.
The MN should (or MUST) be able to support both tunnelling schemes. Why
would you restrict the MN to only using IP-in-UDP in all cases?

> full (both IP tunnel and UDP tunnel) implementations.

And so far at least the consensus from what I can tell is to have the HA
decide what encapsulation mode to use. Hence if you have an MN that only
implements IP-in-UDP and the HA rejects such encapsulation mode, the MN is
pretty much out-of-luck. And as has been mentioned the MN cannot command the
HA to honor its request for IP-in-UDP encapsulation. The decision point is
the HA and lets stick with that design approach.

> requesting to allow some limited implementation which is still

What you are requesting is that if the MN were to request IP-in-UDP
encapsulation, the HA MUST honor it. Otherwise there is no interoperability
with the HA since the MN does not implement IP-in-IP encapsulation.

What is your main argument about or use-case/scenario where you have this
limited implementation (IP-in-UDP only encapsulation) MN?

I guess you do actually have limited interoperability because if the MN
requests IP-in-UDP encapsulation you have a 0.5 probability that the HA will
accept it. So you have interoperability possibility 50% of the time and when
the HA rejects it, well... No connectivity.

-Raj