Subject: Re: FW: [manet] I-D ACTION:draft-cha-manet-extended-support-globalv6-00.txt

From: Christophe Jelger <[email-masked]>
Date: Tue, 04 Nov 2003 14:44:31 +0100

Hi again HyunWook,

I also read your draft, and have a few comments about it.

First, don't take it as an offense, but it is sometimes quite hard to 
read (I'm not saying mine is easier to read !), especially the part with 
the locator (section 5.2). I'm sometimes still not sure I understood 
things as you are expecting people to understand them.

So as far as I got it, a node first acquires a global address (or more, 
one for each gateway ?) valid for GLOBAL_IP_LIFETIME (by the way you 
don't mention how long that should be). Then if there is no route entry 
for the (current ?) gateway, the node can use another GW in a MIP 
manner. Well roughly I understand your proposal, but it's all the 
details I don't understand well that bother me. My main advice is that 
you maybe try to rewrite this section and maybe include an example (in a 
step-by-step way).

In fact I have many questions and in the mean time I don't know where to 
start because I'm not sure I understood the details. So silly questions 
are :

- Each node configures a global address for each gateway ? Or just when 
it needs a locator ?
- The idea to redirect packets arrving at a given gateway through 
another gateway from which ad hoc node is reachable seems good but I'm 
not sure whether it is realistic or not. For example, at some point 
there might be a cascade of such registrations, how do you handle that ?
- I'm not sure about the complexity of your proposal if you want to 
implement it. Can you tell us more about that ?
- Your proposal induces packet encapsulations, which is quite hungry in 
resources (an extra header in all packets). Routing becomes sub-optimal 
(i.e. triangular).
- I think your proposal induces a large number of security issues around 
locator registrations : Node B registers a locator with a gateway G for 
address of node C (and gateway of C will forward packets to G that will 
forward them to B). Is this possible ?

I'm sorry I can't give more feedback, mainly because I think I 
understand your proposal roughly but not deeply.

Regards,

Christophe

HyunWook Cha wrote:

> Hello, folks.
> 
> As far as I know, research works have been performed in Internet
> connectivity for MANETs continueously until now.
> I think that MANET wg members also consider this issue as important one
> to be addressed in the working group.
> My question is if this issue will be discussed in the 58th IETF meeting
> or not.
> 
> Regardless of answer for the above question, I request comments or
> advices for the following draft submitted by me.
> 
> Regards,
> 

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

---

From: "HyunWook Cha" <[email-masked]>
Date: Thu, 6 Nov 2003 11:40:26 +0900

Hello, Christophe.
Thanks for your interest in my draft.
Please see my comments below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christophe Jelger
> Sent: Tuesday, November 04, 2003 10:45 PM
> To: [email-masked]
> Subject: Re: FW: [manet] I-D 
> ACTION:draft-cha-manet-extended-support-globalv6-00.txt
> 
> 
> 
> Hi again HyunWook,
> 

Your summary is right.

Thank you for your advice. I apologize that my bad composition bothered
you. :-) I will revise this I-D as soon as I can. 

> - Each node configures a global address for each gateway ? Or 

Every node configures a global address per a gateway. As you know, while
global address acquition in Wakikawa's draft is in stateless manner
similar to RFC 2462, this is performed in stateful manner. 
So, a manet node should request assignment of its global address to
availabe gateways in my draft. If unsolicited gateway
advertisement(GW_ADV) is issued periodically by gateway, a manet node
can request address assignment by unicast GW_SOL using route informaiton
from received GW_ADVs. Otherwise, a manet node can obtain its addresses
from reachable gateways by broadcasting GW_SOL. 

As I mentioned in my draft, locator candidates are subset of configured
global addresses of a node. 
  
> another gateway from which ad hoc node is reachable seems 
> good but I'm not sure whether it is realistic or not. For example, at
some point 
> there might be a cascade of such registrations, how do you 

Good question. I also think that a cascade of locator registrations
should be avoided. To address this problem, I added following
requirement for locator registration. Firstly, a manet node checks that
cared address(being used to current active sesstion) is being used as a
locator of another global address or not. Only if the cared address is
not being used as locator, it performs locator registration. Secondly, a
manet node should use global addresses as candidates of locator which
are not being cared through previous locator registrations. However,
these requirements are not sufficient to avoid this issue since
information related locator registration in a manet node can be
inconsistent with information in gateway, which can be occurred
ocassionally in nature of manet. Thus, in my draft, gateways are
responsible for cascaded locator registration problem. That is, when
gateway which assigned locator address receives a LOC_UPDATE, it filters
out the message if locator in the message is being cared through
previous locator registation. If not, the gateway updates
loc_service_expire in node_entry for locator in the message to current
time plus LOC_SERVICE_LIFETIME(10 secs). By doing this, locator is not
allowed to be cared through upcoming locator registrations as long as
loc_service_expire is valid. In addition, when gateway which assigned
the address for which the LOC_UPDATE was issued receives a LOC_UPDATE,
it filters out the message if it is possilbe that the cared address is
being used as locator for another address, in other words,
loc_service_expire for the cared address is valid. In this way, this
issue can be handled simply. 
  
> implement it. Can you tell us more about that ?

Actually, I have written NS-2 simulation codes for my draft except for
implicit ack related to address refresh as well as locator registration.
In my codes, I also considered next hop forwarding strategy instead of
routing header. But big difference between you and I is that multiple
global addresses are configured and maintained in very natural manner,
and source address based forwarding is performed in intermediate nodes
on a path to a gateway thereby avoiding use of routing header. For this
scheme, logical prefix continuity is necessary. That is, all
intermediate nodes should have corresponding GW_INFO for the prefix of
source address in a received packet. As for complexity, Uhm...
Currently, I did not yet analyze the complexity of my draft deeply.
Basically, idea is simple but applicability to manet requires addtional
considerations as my draft describes. Although, I tried to perform
efficiently my scheme, room to be modified and enhanced may be left in
my draft.    

> resources (an extra header in all packets). Routing becomes 

Right. Tunneling using registered locator should be done as
restictively(limitedly) as possible. Basically, I propose this scheme as
advanced functionality for basic internet connectivity support. So, a
gateway can forward using route entry for a manet node instead of
tunneling using locator when the gateway knows fresh route information
throgh normal route discovery by the manet node (in case of
bidirectional communication) or the gateway itself. Please, think about
the case where a gateway can not obtain route information for
destination manet node because of a little bit long-term partition. In
this case, my scheme can be helpful since it can help upper layer
session keep going safely. I think this has big advantage over some
nonobtimal routing or bandwidth consumption by encapsulation. 
 
> forward them to B). Is this possible ?

Right. As Mobile IPv6 needs securiy associations between HA and a mobile
node to authorize a binding update, security concern is also a critical
issue in my draft. As you read section 6, this is out of scope for the
initial version. As I mentioned in my draft, I am cosidering basic
security mechanism for routing protocols (update of route entry actually
requires secure mechanism needed for authentication of destination node)
as well as additional method. I wonder that IPSec can be applied to my
scheme efficiently. IMO, more than two way handshake to establish
security association can not be adapted in manet. Enhanced Diffi-Helman
method can be used, too. Again, I will describe in more detail in
revised version.

> understand your proposal roughly but not deeply.

I hope that my explanation can help you understand more deeply and you
can give important comments. 

Thanks in advance.

HyunWook Cha