Subject: RE: [mobile-ip] Multiple tunnels over unoptimized route packets f or Extended mode

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 30 Mar 2001 02:52:26 +0200

> > >
> > > Packets from the MN's HA would arrive tunneled at that LCoA (route unoptimized)
> > > (one tunnel)
> > > In that time the vehicle that was carrying that MR/MAP  went away. That means to
> > > me, that the MR acts as an HMIPv6 node and as a MR/MAP. So what does it do? It
> > > gets itself a RCoA on a fixed MAP (Hello Basic Mode). That fixed MAP will tunnel
> > > all packets sent to that RCoA.
> > >
> 
> >
> >         => For the second time, a fixed MAP does NOT mean basic mode. It
> >         can be an Extended mode MAP.
> >
> 
> Now allow me to say that the spec (v2) mentioned explicitly that the MR case is
> explicitly worked through extended mode. 
> 
	=> Correct.

> In that case I can only assume that the
> fixed MAP case is dealt by the Basic mode. 
> 
	=> The spec says, that Extended mode can handle the MR case and 
	the normal (fixed) case. Basic mode can only handle the fixed case. 

	So just because a MAP is fixed that doesn't mean it has to be 
	Basic mode, either one would work.

> If you say that the fixed map case is NOW,
> NOT dealt by basic mode, 
> 
	=> Did I say that ??? I said both modes can handle it.

> I am left with no option but AGREE with Charlie on his
> request that the Basic mode should really go AWAY... I cannot see any point why the
> basic mode need stay there anymore. I would be grateful if you could convince me for
> the opposite....
> 
	=> I can try. BTW there is a coparison between the two modes 
	in the draft. 
	Anyway, Basic mode provides some features that Extended mode
	doesn't. For example location privacy is one of the major advantages. 

	Also Basic mode does not require any modification to the HA. 
	Extended mode does. This is needed to enable forwarding of 
	packets addressed to the MN's Site local home address. 

	In addition if we work out a redundancy mechnism for MAPs
	or HA's then it would be much easier to design it for 
	Basic mode.

	So there are pros and cons for each one. Since the interface
	(MAP option and BU) to the MN is very similar, we thought 
	it would be a good idea to have both. 
	Also people on this list and others expressed interest in 
	having Basic mode for location privacy to hide the 
	operator's addresses (in outgoing packets). 

> I need not emphasize further as negative point of Basic mode,  that the generation of
> multiple RCoA for MN so as to sustain unique representation of the MN in the visited
> domain, while you have a unique Home Addr already at hand (but you don't divulge that
> to the MAP - I wonder why???) is also bound to find problems:
> 
> 1) by the management of MANY RCoA for no apparent reason
> 
	=> Where does MANY come from ? Only one is needed.
	or does MANY = MANY MNs ? If so how is it different 
	in the HA case.

> 2) DAD checks by the hunderds for no apparent reason
> 
	=> hundreds ? where does a hundred come from ?
	You mean hundreds of MNs ? Actually there 
	maybe hundreds of thousands ! But the same goes 
	for the HA. 

> If however the Basic mode is destined for fixed MAPs then, all I am crying out loud
> is that when route unoptimized packets leaving from the MN's HA (when that HA has not
> received a BU from the MN because it awaits its MR/MAP to get its own LCoA in the
> mean time) 
> 
	=> Let me get this right. You're saying the MN's HA already has a binding 
	for the MN. This binding was based on the MN's previous location (before
	it appeared on the MR's subnet) Correct ?

	If the MN doesn't / can't send another BU to its HA because it doesn't 
	have the MR/MAP's address or because the MR disappeared (ie. no 
	connectivity) then packets from its HA will be delivered to the old 
	address, ie. lost. 

> towards the MN,  AND the MR is away but the BU from the MN has not reached the MN's> 
> HA (MR/MAP has not got yet  its own LCoA), then the MR/MAP's HA will have to> 
> intercept the packet and tunnel it to the RCoA
> 
	=> How does the MR's HA do that ? How can it even receive the 
	MN's packets ?
	If the MR's HA is the same as the MN's HA then the MN isn't
	 reachable and it doesn't even know that it
	moved because it is still receiving its Home RA. 

	If the MN's HA is different from the MR's HA, then the packets 
	will never be tunnelled or even received by the MR's HA. 
	This is the problem identified by Thierry's draft. This is 
	a problem in MIPv6 but you seem to assume that it's 
	solved and that the MR's HA will just tunnel packets
	for the MR's entire subnet.
	Have you read Thierry's draft ? If not then reading it 
	would help.

	Packets from the CN to the MN will be tunnelled by the MN's 
	HA to the CoA in the Binding Cache. If there is no entry
	there is no tunnelling. If there is an entry that is no longer
	valid (because the MN moved) the HA will comtinue tunnelling
	to that CoA in the Binding Cache regardless, until it's 
	given a new CoA. I really can't see how the scenario you're
	describing is possible.

	Hesham

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 30 Mar 2001 09:23:11 -0800

Hi Hesham,

   more elaboration below,

>         Basic mode, either one would work.

correct. This is unquestionable. But till now in our discussion you have not showed me
where Basic Mode is used for the fixed case. Remember you have to setup/configure manually
the thing. So once you describe for fixed nodes that Basic mode is used and then when the
extended mode comes in you swap the use of basic mode for the fixed MAP case with extended
mode. How are you going to reconfigure your MAP and advertising point manually?  Is there
a magic stick around? By the time you configure things manually (yeah right ...out of
scope for this document but basicaly the beast is hiding inside it....) then you have to
stick by your guns...you can't just say that the spec does not preclude it...sure it
doesn't...as it sure doesn't preclude that the thing is not going to work if the spec goes
on like that..because we have to stick with something with this spec in this version not
one coming out sometime soon..

You could ponder for ever for 'potentially' nice things of Basic mode but hey tell me
where are you using the thing but consistently...otherwise I will get a headache and drop
using the spec alltogether as an implementor...

>         => Did I say that ??? I said both modes can handle it.

yes the spec says that but reality proves the opposite when it comes to it...just follow
the reasoning..(if you want that is...)

>         Anyway,

you can try but you don't...this is the problem in this sort of interactions..I never get
the answer

> Basic mode provides some features that Extended mode

location privacy for who ?

the MN with respect to the visiting domain  (1)
       or
the MN with respect to the world. ?????? (2)

(1)   the MN with respect to the visited domain is certainly not hidden. The MAP knows its
LCoA so that it can tunnel to it.
(2)    the MN with respect to the world is definetely not hidden. Remember that upstream
you send packet with your src addr as the LCoA as the egress filtering won't let you out.
Also you do not specify anywhere that upstream data packets have the source addr as the
RCoA, and you know very well why.

So if a node really wants to get the so called private LCoA of the node it simply bypasses
the core CN functinality (on its own box) by not substituting the src addrs with the Home
Address dest option. And that will be the end of location privacy. When it comes to
security people are not
holding a cross in their hands..they are really nasty. And to bypass that CN function is
only easy

so location privacy is a gonner...

>         packets addressed to the MN's Site local home address.

Sure the extended mode does what different to the MAP (so-called HA) it keeps the home
address instead of the RCoA in the B-Cache and detunnels before it retunnels....year
right....this is too much...I don't think this wins as an argument..with all due
respect...

>         or HA's then it would be much easier to design it for

In greece we have a saying that if my dog had wheels he would be a skateboard....I think
you are providing me with a similar argument here...
consider: you are designing a whole mode in the core of the protocol for something that is
out of scope of the core of the protocol....hmmmmm
I could then say with no remorse that this is DEFINETELY OUT of the scope of this draft...

By the way don't get picky now about the comment...see what I mean behind it....

>         operator's addresses (in outgoing packets).

operator's addresses ....?????   you mean the LCoA...please see above...

I would like to hear people that ARE supporting location privacy through HMIPv6 on that.
Please give me some arguments as well. If I cannot hear anybody I don't think they
exist.....

>         or does MANY = MANY MNs ? If so how is it different

ok back to the spec. The basic mode mentions that an MN is receiving the MAPs prefix and
creates a CoA. This is the RCoA that is sent back for DAD to the MAP. I can only assume
that each MN will create a different RCoA in Basic mode, since this is the entry in the
home addr option B-Cache of the MAP. THAT MUST BE UNIQUE and thus one per MN. That implies
if X is the number of registering MNs with THAT MAP then X will be the number of
DIFFERENT RCoAs in the B-Cache of THAT MAP. This is of course unless all MNs conspire and
produce one RCoA but then the B-Cache in that MAP is useless....

>         maybe hundreds of thousands ! But the same goes

According to the above reasoning you will have as many DADs as RCoAs for the X number of
MNs registering under that MAP.

>         it appeared on the MR's subnet) Correct ?

No the binding in the MN's HA maintain (at that moment in time) the last  IP address (the
last LCoA) of the MR/MAP before it flew off.

>         connectivity) then packets from its HA will be delivered to the old

Nooooooooope.... remember that in extende mode you have given to the MN's HA the IP
address of the MR/MAP in that MR/MAP home domain.
Now the MR/MAP has flown off. So as far as the protocol is concerned the MR/MAP is just
another HMIPv6 node. So what does that node do. It provides to its HA (that is the
MR/MAP's HA) its latest binding. This MUST be a RCoA since it registers with fixed MAP. So
the HA of the MR/MAP/HMIPv6 node will now intercept all packets that come on its IP
address. That includes all packets that arrive tunneled from the MN's HA according that
the aformentioned binding. That is the old IP address of the MR/MAP as the alt-CoA for the
MN BEFORE the MR/MAP/HMIPv6 node flew off !!!!!!!!!!!!

So guess what...one more tunnel from the MR/MAP/HMIPv6 node on the received packets from
MN's HA... (this make a total of 2 so far). The third is effected by the fixed MAP as a
good old HA local instantiation....

>         => How does the MR's HA do that ? How can it even receive the

That is the thing I am not talking about upstream packets (the MN is still waiting on the
MR/MAP/HMIPv6) to get its own LCoA and attach on a subnet. so no BU to it HA yet...

I am talking about downstream packets sent tunneled by the MN's HA. That is packets coming
from new CN's towards the MN. They will have to go through the MN's HA and they get
tunnelled and blah blah ...see above...

>         moved because it is still receiving its Home RA.

I did not say such a thing in the slightest...wrong turn here... both HAs are different
and defend different addr

The MN's HA is intercepting packets at that time for the MN's home address. But in
extended mode it has to destine them to the MR/MAP/HMIPv6 node IP address (remember?)
The MR/MAP/HMIPv6's HA is intercepting packets that arrive to the IP addr of that
MR/MAP/HMIPv6 node...Guess what these are (since it is a router)...they are (among others)
packets that arrive tunneled to the IP addr of the MR/MAP/HMIPv6.....see?

>         Have you read Thierry's draft ? If not then reading it

not so fast here....in extended mode the MN is providing the IP addr of the MAP. If the
MAP moves (MR) it behaves like a standard HMIPv6 node. So it needs a HA to intercept
packets for it. Again guess what these packets are? Amongs others, packets that arrive
tunneled to the MR/MAP/HMIPv6 node. So who will intercept them???? .....the MR/MAP/HMIPv6
node's HAAAAAAA.....so another encapsulation until the fixed MAP of the MR/MAP/HMIPv6
node....

>         given a new CoA. I really can't see how the scenario you're

Yes but what is the
CoA......?????????????????????????????????????????????????????????????????????????
the IP addr of the MR/MAP/HMIPv6 node...so the packet will arrive somewhere and will be
encapsulated again as soon as the HA for that MR/MAP/HMIPv6 intercepts them...

Basic assumption here....all nodes have a HA when moving.... even MR/MAP/HMIPv6
nodes......

So you just said it but did not continue here....please move your thoughts on that
scenario...I think you do see it ..... :)))))))

If you still cannot see the scenario...I seriously suspicious here....just to make it a
little more fun...I think you need to take off the Ericsson hat (understandable), again
with all due respect....and put your research engineer hat on

and a great day to all

Theo

UCL / Mobile Systems