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

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 20 Mar 2007 15:29:20 +0000

New submission from Keiichi SHIMA <[email-masked]>:

The current DSMIPv6 draft specifies two encapsulation formats, one is the IPv4 encap format, the other is 
UDPv4 encap format.  The default encapsulation format is the IPv4 format, and if the HA explicitly 
specifies to change the encapsulation format to the UDPv4 format if there is a NAT box between the HA 
and the MN.  Because of this specification, HA and MN have to support both encapsulation formats and 
have to change the format dynamically, that may increase the hurdle for implementors and may cause 
complexity in interoperability.

Isn't it possible to fix the encapsulation format to one of these mechanisms described in the draft?

----------
category: Technical
draft: draft-ietf-mip6-nemo-v4traversal
messages: 338
nosy: keiichi
priority: May fix
status: No discussion
title: fixing encapsulation mechanism in IPv4 network

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue94>
_________________________________________________

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Mar 2007 17:03:10 +0100

I agree only one encapsulation mechanism (for traversing IPv4) is 
something useful, as opposed to implementing always two encapsulating 
mechanisms.

I'm not sure that UDP is the right answer for that.  IPv4-in-IPv4 
mechanisms (without UDP) have their advantages: less packet overhead. 
They have inconvenients that they should be mainly in kernelspace 
(constraints).

Would it be possible to have DS-MIPv6 implementation with one big MIB 
knob that says:
-use UDP for BU signalling, traffic encap and NAT traversal.
or
-use IPv4-in-IPv4 for BU signalling, traffic encap and NAT traversal.

But I'll agree with what's suggested as already implemented.

Alex

> Isn't it possible to fix the encapsulation format to one of these mechanisms described in the draft?

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 20 Mar 2007 09:59:54 -0700

Hello,

> complexity in interoperability.

If I remember right, this was among the first few issues that
were discussed in the design team. Some folks did suggest
turning on UDP all the time when the access network is IPv4.
But this is an overhead in case there is no NAT. Thats why
we have a NAT detection mechanism in the DS-MIPv6. UDP
encapsulation is turned on only if a NAT is detected. My
preference is to still go with this.

> Isn't it possible to fix the encapsulation format to one of these mechanisms described in the draft?

If we are to pick only one encapsulation format, we clearly
can't pick "IPv4 encap format" (as you called it) because it
may not work through a NAT. It has to be UDP encapsulation
always.

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 21 Mar 2007 04:25:12 +1100

Keiichi, 

We will have a formal concensus call on this but let's here a few opinions
first. My opinion below:

 > The current DSMIPv6 draft specifies two encapsulation 
 > formats, one is the IPv4 encap format, the other is 
 > specifies to change the encapsulation format to the UDPv4 
 > format if there is a NAT box between the HA 
 > and the MN.  Because of this specification, HA and MN have 
 > to support both encapsulation formats and 

=> So basically you're asking for UDP-only tunnelling. As I mentioned in a
previous email, this a tradeoff between reducing the implementer's work and
reducing redundant bits on the wire. I think it makes more sense to reduce
additional bits on the wire. The UDP tunnel is redundant if no NAT were
detected. So your suggestion amounts to removing NAT detection and always
using UDP tunnels. I think this is inefficient, especially when the cost of
switching between the UDP tunnel and IP n IP is very small (from an
implementation point of view). 

Hesham

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 09:13:27 +0100

Vijay, 

[snip]

> But this is an overhead in case there is no NAT. Thats why we 
> have a NAT detection mechanism in the DS-MIPv6. UDP 

Honestly, based on our small MIP deployment experiments & experience
the NAT traversal has been kind of secondary (but a good additional)
feature. The greatest value of UDP encapsulation has been the firewall
traversal.

Cheers,
	Jouni

> may not work through a NAT. It has to be UDP encapsulation always.
> 
> Vijay
> 
> > 
> > ----------
> > category: Technical

---

From: Keiichi SHIMA <[email-masked]>
Date: Wed, 21 Mar 2007 19:12:57 +0900

Hello,

On 2007/03/21, at 1:59, Vijay Devarapalli wrote:

>> The current DSMIPv6 draft specifies two encapsulation formats, one  
>> is the IPv4 encap format, the other is UDPv4 encap format.  The  
>> default encapsulation format is the IPv4 format, and if the HA  
>> explicitly specifies to change the encapsulation format to the  
>> UDPv4 format if there is a NAT box between the HA and the MN.   
>> Because of this specification, HA and MN have to support both  
>> encapsulation formats and have to change the format dynamically,  
>> that may increase the hurdle for implementors and may cause  

I agree that using UDP has an overhead compared to a simple IP  
encapsulation format.

My question came from the idea that 'which is the major environments  
for IPv4?  A NATed environment or a global IPv4 environment?'  If  
most of the IPv4 networks that the mobile terminals connect to is  
NATed networks, then simply using UDP seems better to me.

But my perspective may be wrong.  I want to hear some more opinions  
from who are interested in DSMIPv6 operation.

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

---

From: Keiichi SHIMA <[email-masked]>
Date: Wed, 21 Mar 2007 19:20:46 +0900

Hello,

> We will have a formal concensus call on this but let's here a few  

OK, thanks.

> using UDP tunnels. I think this is inefficient, especially when the  

About the possibility of using the UDP encap mechanism, please refer  
my mail replied to Vijay's mail.

> 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 would like to hear opinions from who have already implemented DSMIPv4.

---
Keiichi SHIMA

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 21 Mar 2007 21:40:16 +1100

> 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: Romain KUNTZ <[email-masked]>
Date: Thu, 22 Mar 2007 14:41:38 +0900

Hi Shima-san,

Keiichi SHIMA wrote:
> 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.
> 

On linux, we perform UDP encapsulation/decapsulation for signaling using 
the packet transformation framework XFRM. Encapsulation/Decapsulation is 
thus performed in the kernel space.

We can easily switch from one mode to the other from the userland 
through netlink (socket-based interface for communication between kernel 
and userland processes).

XFRM is very flexible and rather easy to extend to implement parts of 
the DSMIPv6 spec.

Regards,
-- 
Romain KUNTZ
[email-masked]

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 22 Mar 2007 16:23:00 +0900

Hello Hesham,

> always end up having to support both types of tunnels whether we  

What I wanted to remove is the switching mechanism of encapsulation  
format when a mobile node is in the IPv4 network.  Currently, our  
implementation does not support IPv* in IPv4 encapsulation mechanism  
because of course MIPv6 doesn't require that.  If we a mobile node is  
allowed to use only the UDPv4 encapsulation mechanism, then we wanted  
to implement that.

But, as Romain said in other mail, at least it seems easy to  
implement both IPv4-encap and UDPv4-encap and switching between them  
in Linux.  So it depends on the design of implementation.

So, I want to propose a compromise.  Isn't it possible to add a flag  
for a mobile node to declare that the node wants to use the UDPv4  
encapsulation mechanism when sending a binding update message to its  
home agent?   Hesham said to me in our local conversation yesterday,  
such a flag already exists in the current spec, however, I re-read  
the text and couldn't find such a flag.

There is the 'F' flag to force the UDP encap format, but it is for a  
home agent and not for a mobile node.   In the current spec, a mobile  
node doesn't have any freedom to choose the encapsulation mechanism,  
only HA can force a mobile node to use UDP encapsulation.

If a mobile node can have such a flag, then nodes that want to use  
IPv*-in-IPv4 format can still keep the current encapsulation  
mechanisms (that is, IPv*-in-IPv4 by default and switch to UDPv4  
whenever necessary), and nodes that want to support only UDPv4  
encapsulation can specify its request in a binding update message  
using the newly added flag.

Is it feasible?

We (Koshiro Mitsuya, one of the developers of our MIPv6  
implementation) will send proposed text mentioning the above  
mechanism later.

---
Keiichi SHIMA

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 22 Mar 2007 17:04:08 +0900

Hello Alex,

On 2007/03/21, at 1:03, Alexandru Petrescu wrote:

> something useful, as opposed to implementing always two  
> encapsulating mechanisms.
>
> mechanisms (without UDP) have their advantages: less packet  
> overhead. They have inconvenients that they should be mainly in  
> kernelspace (constraints).
>
> Would it be possible to have DS-MIPv6 implementation with one big  
> MIB knob that says:

It should work.  But what do you think about the idea to add a flag  
to specify the encapsulation mechanism in a binding update message as  
proposed in my mail to Hesham?  With the proposal, we don't need any  
manual configuration knobs and we can still use IPv*-in-IPv4  
mechanism, but allowing nodes that want to UDPv4 encapsulation only.

Regards,
---
Keiichi SHIMA

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Mar 2007 15:00:25 +0200

Keiichi SHIMA wrote:
>> MIB knob that says: -use UDP for BU signalling, traffic encap and
>> NAT traversal. or -use IPv4-in-IPv4 for BU signalling, traffic
>> encap and NAT traversal.
> 

I think it could work (flag set by MN to specify UDP or IP encapsulation).

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

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.

Alex

---

From: "Zhang, Qiang [NTK]" <[email-masked]>
Date: Mon, 26 Mar 2007 10:55:30 -0500

Hi, 

>From an operation point of view, both or more tunneling options should be supported so to make the deployment flexible. Only HA knows whether the device is traversing through NAT devices, therefore the decision will have to be made jointly by MN and HA. I would think MN can send preference setting flag to mandate or option-ize the UDP tunneling, 

If MN choose to option the UDP tunneling
	if (NAPT happened determined by HA)
		HA should set a flag inform MN to mandate the UDP tunneling
	if (NAPT does not happen determined by HA & HA mandate the UDP tunneling)
		HA should set a flag inform MN to mandate the UDP tunneling
      if (NAPT does not happen determined by HA & HA only option the tunneling)
		HA should set a flag inform MN to optionize the UDP tunneling
Else if MN choose to mandate the UDP tunneling
	if (NAPT happened)
		HA should set a flag to mandate the UDP tunneling
	else if (NAPT does not happen & HA mandate IP-IP tunneling)
		HA should set a flag to mandate IP-IP tunneling
	else if (NAPT does nto happen & HA optionize the tunneling)
		HA should set a flag to optinize tunneling

Then the MN will be able to choose from the joint decision from those decision logics either mandate or optinize the tunneling scheme

Also when saying NAPT, as long as there is port number change it should be considered that a NAPT happened and the midbox won't be friendly to IP-IP tunnel (well there may still be devices that are really weird they are out of scope I would say); keep-alive timer is a potential loophole in the design as there is no way to understand the timers in the NAPT state machine on those devices, therefore it is a system wide parameter to be tuned along the path.

RFC3519 should be referenced as most of the items had been discussed before

Thanks!
-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Monday, March 26, 2007 8:00 AM
To: Keiichi SHIMA
Cc: [email-masked]
Subject: Re: [Mip6] [issue94] fixing encapsulation mechanism in IPv4 network

Keiichi SHIMA wrote:
>> knob that says: -use UDP for BU signalling, traffic encap and NAT 
>> traversal. or -use IPv4-in-IPv4 for BU signalling, traffic encap and 
>> NAT traversal.
> 
> It should work.  But what do you think about the idea to add a flag to 
> specify the encapsulation mechanism in a binding update message as  

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

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.

Alex

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 28 Mar 2007 17:33:25 +1000

Kiichi, all, 

I think we've seen the different angles of this issue now and it's time to
close it. 
So I suggest that we choose one of the two options listed below. 

Folks, 

The "new" issue is about whether or not the MN can request one form of
tunnelling (i.e. UDP) when sending a BU to the HA. The two choices we have
are:

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, 

B. Do nothing. I.e. the MN sends the BU as described in the spec today and
the HA tells the MN in the BA whether it should use UDP tunnelling or IP in
IP. 

Please express your preference for one of the options above. Let's not make
things complicated and get into negotiating the tunnelling mechanism, one of
the two above will suffice. 

I'll leave it open till next Tuesday. 

Thanks,
Hesham

---

From: <[email-masked]>
Date: Wed, 28 Mar 2007 11:08:40 +0300

Hi,

As was indicated in some earlier email, in some environments the problem
is not so much the NATs but the FWs that
don't allow IP-in-IP to pass. We have encountered this in our tests as
well. 
I'd like to give the MN the choice to select whether to use UDP
tunneling or not (= prefer option A).

-Markku

>From: ext Hesham Soliman [mailto:[email-masked]] 
>Sent: 28 March, 2007 10:33
>To: 'Keiichi SHIMA'
>Cc: [email-masked]
>Subject: [Mip6] concensus on [issue94] fixing encapsulation 
>mechanism inIPv4 network
>
>Kiichi, all, 
>
>I think we've seen the different angles of this issue now and 
>it's time to close it. 
>The "new" issue is about whether or not the MN can request one 
>form of tunnelling (i.e. UDP) when sending a BU to the HA. The 
>two choices we have
>are:
>
>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.
>B. Do nothing. I.e. the MN sends the BU as described in the 
>spec today and the HA tells the MN in the BA whether it should 
>use UDP tunnelling or IP in IP. 
>
>Please express your preference for one of the options above. 
>Let's not make things complicated and get into negotiating the 
>tunnelling mechanism, one of the two above will suffice. 
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Mar 2007 11:12:42 +0200

I prefer 'A'.

MIPv4 NAT traversal has that feature, and it is appreciated.

	Henrik

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 28 Mar 2007 12:22:30 +0300

Hi,

I prefer the option'A'.. looks like MIPv4 NAT feature that we have had 
positive experiences, with both NATs and especially traversing FWs.

Cheers,
	Jouni

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 28 Mar 2007 02:48:09 -0700

I prefer option 'B'.

The MN doesn't really know if there is a NAT on the path. It also
does not know if there is a firewall in the path blocking IP-in-IP
packets. Since it does not know any of this, I am afraid many
mobile node implementations will always be setting this flag. Then,
if the HA is allowed to override this, then aren't we basically
saying HA decides whether the MN should use UDP tunneling or not?
This means option 'B' is what is being used to decide whether UDP
tunneling is used or not.

What am I missing?

Vijay

---

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Mar 2007 14:11:01 +0200

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

> flag, that results in using IP-in-IP encapsulation

Ok.

> 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 

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

>> parameters negotiation between MN and HA, before sending the 
>> BU/BAck.  Also periodic heartbeats with re-negotiation if 
>> necessary.
> 
> 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

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

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 28 Mar 2007 06:54:53 -0700

I prefer option "A". 

Reason:
>From the MIP4 experience, many times and for various reasons,
deployments choose UDP Tunneling even in the absence of NAT. The
ability for the client to hint that choice from any connected
network is important. I remember at least in one case, the UDP
tunneling was required by the client over satellite link, for some
reason, using RBSCP ..., there was no NAT in the path. So, the
negotiation logic in 3519 works quite well, IMO. We should probably
go with the same logic.

HA (Forced Accept)
==================
a.) NAT Present

Always enable UDP tunneling

b.) NAT not present

Enable UDP tunneling if the MN sets the bit

HA (Forced Reject)
==================

a.) NAT Present

Always enable UDP tunneling

b.) NAT not present

Do not accept UDP tunneling, even if the client requests it.

Besides the "U" bit in the request, the HA should have some
config policy on to accept "forced" UDP tunneling or not. So,
the final control can be given to the HA in the form of policy, 
but the client should be able to specify its preferences.

Sri

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2007 12:33 AM
To: 'Keiichi SHIMA'
Cc: [email-masked]
Subject: [Mip6] concensus on [issue94] fixing encapsulation mechanism inIPv4
network

Kiichi, all, 

Folks, 

Thanks,
Hesham

---

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

Sri Gundavelli wrote:
> network is important. 

The problem is that the client may not know. It might be
setting the flag all the time. Do we have a mechanism to
say when the MN should be setting this bit?

> config policy on to accept "forced" UDP tunneling or not. 

Agree on this.

Vijay

So,

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 28 Mar 2007 07:39:42 -0700

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2007 7:32 AM
To: Sri Gundavelli
Cc: 'Hesham Soliman'; 'Keiichi SHIMA'; [email-masked]
Subject: Re: [Mip6] concensus on [issue94] fixing encapsulation mechanism
inIPv4 network

>say when the MN should be setting this bit?

The preference comes from the type of connected access network
and other characteristics local to that network. So, the mobile
node is in a better position to make that choice. Off course,
the home agent always has the final say, in the form of configured
policy. 

But, sure, the logic as when to enable this on the mobile is
difficult. Mostly, it might be an operator initiated explicit
setting, on a need basis.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 28 Mar 2007 07:45:23 -0700

> the home agent always has the final say, in the form of configured

So can we then add a sentence saying

   It is recommended that the mobile node SHOULD NOT set the 'U'
   flag by default, since using UDP encapsulation when not
   required introduces an unnecessary overhead for all data traffic. :)

My preference is still for 'B' though.

Vijay

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 28 Mar 2007 09:47:52 -0500

I believe we should do the following:

1- MN should be able to set a request for UDP tunneling.
2- the default behavior for MN is not to set the request.
3- The HA should be able to accept or reject.

---

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

Hi Vijay

> tunneling is used or not.

HA override should not be a dynamic thing, rather a matter of whether
UDP tunnelling is configured as permitted on the HA at all.

Having the UDP tunnelling request flag makes it possible for a client
to detect an anomalous situation and try to fall back to UDP tunnelling
if IP-in-IP just doesn't work.  Not having the flag deprives the system
of this fallback option.

In MIPv4 we've repeatedly seen that it's useful to have this flag.

	Henrik

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 30 Mar 2007 06:04:48 -0700

I prefer A, since I think it is good to allow the mobile to request UDP
tunneling for whatever reason.

I agree with Vijay that it is not clear how the MN should decide to make
such request. Indicating that the MN SHOULD NOT be setting the U flag by
default is a good idea. Another BCP type text could instruct
implementers to try setting the U flag if things are failing with no
apparent reason...e.g., registration apparently works but no data are
ever received... maybe due to a FW on the path.

There is also an almost parallel discussion on whether the HA should be
able to override a request or not. I do not think you can "force" an HA
to do anything...this is why such things are called "requests" and not
"commands". I think the correct thing to do here is to allow the HA to
reject the BU with an error code set to something like "UDP Tunneling
not allowed". It is then up to the MN to try to reregister with U flag
set to "0" or to give up.

Thoughts?
George

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2007 3:45 PM
> To: Sri Gundavelli
> Cc: [email-masked]; 'Keiichi SHIMA'
> Subject: Re: [Mip6] concensus on [issue94] fixing encapsulation
> mechanisminIPv4 network
> 
> Sri Gundavelli wrote:
> >
> >