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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 1 Apr 2001 19:04:32 +0200

> > Basic mode provides some features that Extended mode
> >         doesn't. For example location privacy is one of the major advantages.
> 
> location privacy for who ?
> 
> the MN with respect to the visiting domain  (1)
>        or
> 
	=> No.

> the MN with respect to the world. ?????? (2)
> 
	=> Yes.

> (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.
> 
	=> I suggest you read rev 3 of the draft which was sent to the list
	before IETF. If you're new to the list and didn't get it then 
	you'll see it soon on the WG page after submission.

	The MN can certainly send packets with RCOA
	provided the network administrators allow it. 
	This is explained in rev 3 which is currently 
	on Claud's page and will be on the MIP WG
	page this week.

> >
> > > 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.
> 
> 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....
> 
	=> Did you see my last sentence ? How is this different 
	from what an HA has to do ?

> >
> >
> > > 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.
> >
> 
> According to the above reasoning you will have as many DADs as RCoAs for the X number of
> MNs registering under that MAP.
> 
	=> Did you see my last sentence ? How is it different 
	from what an HA has to do ?

> >
> > > 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 ?
> 
> 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.
> 
	=> So the HA has a binding for an address that is no longer
	valid. Ie. can not be used to reach the MN. So the MN
	is unreachable.
	But somehow what you say above contradicts what you say 
	below "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..."

> >         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.
> >
> 
> 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.
> 
	=> If I understand your scenario, you're assuming there is another
	MAP (fixed). In that case that's the address you give to the HA
	NOT the MR's LCoA.
	If the MR disappeared, then the "further" MAP will not be able to 
	route packets to the MN unless it gets another BU.

> 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. 
> 
	=> No it doesn't have to be the MR's HA. Unless the MN's
	HA = MR's HA.

> 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 !!!!!!!!!!!!
> 
	=> I think (I'm trying very hard to understand what you're saying) that
	you're assuming that the MN sends a BU to its HA including the 
	MR's Home address (ie. the MR's address that is on the MN's side). 
	This is not what the draft says. It says that the MN binds
	it's home address to the "further" MAP's address (in its HA
	BU) ,  and the MR's LCoA is used with that further MAP.
	More on the address later.

	So: 
	HA_BU (Home_address, RCoA) RCoA is the "further" MAP's address in
	the extended mode case or the address on the "further" MAP's subnet 
	in Basic mode. 
	MAP_BU (MR's LCoA, Home address (Extended mode) or RCoA in Basic mode)
	The MAP_BU is the BU sent to the "further" MAP. If there is 
	no "further" MAP upstream, then the MR is essentially like an FA and 
	the MR's LCoA is sent directly to the HA. 

	So based on this, the packets addressed to the MN can NOT
	be received by the MR's HA, unless the MR's HA = MN HA.

	The MN's HA will tunnel packets to the CoA in its Binding 
	Cache. That CoA is NOT the MR's Home address. 
	It is either, the RCoA (if a further MAP exists) or the MR's 
	CoA if no other (further) MAPs exist. OK ?

> >
> > > 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 ?
> 
> 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...
> 
	=> As I said above, this is the opposite of what you said earlier.

> >         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.
> >
> 
> I did not say such a thing in the slightest...wrong turn here... both HAs are different
> and defend different addr
> 
	=> Then the MR's HA should never receive the MN's traffic.

> 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?
> 
	=> I don't know how much more I have to say to explain that 
	the MR's HA will NOT receive _the_MN's traffic.
	Where does the draft say that ?
	Pick that part of the draft and send it to the list. If you can find it
	we'lll change it to reflect what I just told you. 

	If the MN sends the BUs I showed above, and then the MR
	(MAP) disappears then it has to update the fixed MAP
	with a new LCoA. Otherwise it's not reachable.

> >         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.
> 
> 
> 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...
> 
	=> NO. It's the LCoA of the MR. The one advertised in its
	MAP option. The one it formed from the RA received from 
	the visited AR or the local DHCP server. 
	The one that belongs to the visited domain and not the 
	Home domain. That one.

	Therefore packets can never be sent to the MR's HA, unless
	it is the same HA as the MN's. Which, as you said, is not the 
	scenario you're describing.

> 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 ..... :)))))))
	
	=> :)))))... Yes I do see that what you described is not what 
	we said in the draft. Perhaps someone else has managed
	to understand what you're saying differently, that is if they 
	understood it at all. 
	If so I'd love to hear what they understood.

> 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
> 
	=> The only hats I try to keep on when I answer your mails
	are my sanity hat and the "filter irrelevant comments" hat.
	But you seem to be trying hard to remove both of them.

	I suggest you stick to the draft and not get this list
	into discussions about my company or my hats. It's not 
	fun or interesting or relevant. 

	Hesham

---

From: Theo Pagtzis <[email-masked]>
Date: Mon, 02 Apr 2001 09:33:44 -0700

Hi Hesham,

>         you'll see it soon on the WG page after submission.

I could do without your patronizing style about revisions on drafts. It seems that every other
week you like to invalidate your previous draft and then call people 'newcomers'  because
Claude may have a new version out.  It does not give much credibility to the draft to rush out
some draft before the deadline only to say "we have corrected some problem" a week
after (pretty serious if you ask me) and then have a new version that often. Please spare me
with this kind of style please? This is BTW bad form of elaboration...

>         on Claud's page and will be on the MIP WG

ok..this is a very good assumption...It is like saying in the future pigs will fly provided
that they are allocated some wings by god...you expect to convince the community with that????

>         from what an HA has to do ?

I think I saw your last sentence pretty well thanks VERY much.  The question is can you read my
comments or do you stop past the second sentence.....Well it is pretty different. When you have
to manage on top of the B-Cache an extra set of RCoAs and do same amount of times DAD then it
gives just a tiny bit more work to the box. But that doesn't bother you at all..does it...when
it comes to count by the millions at the VISITED domain (since the home domain will only
contribute a small portion to that , i.e. aggregation of contributing MN from the distributed
home domain...then perhaps you will see what I mean...but then it will be too late ....

>         and attach on a subnet. so no BU to it HA yet..."

Yes...you got that right...the MN is unreachable BUT the packet is destined to the IP addr of
the MR/MAP...which is away...what would you expect the HA of the MR/MAP to do???

>         route packets to the MN unless it gets another BU.

If you do that then you are breaking your assumption about distance on the RT advert and the
MAP options. Shortest distance is what gets picked by the MN

>         => No it doesn't have to be the MR's HA. Unless the MN's

If the MR does not provide its RCoA to its HA then what does it provide to it? nothing???? this
breaks basic mobility....if it happens...

>         the extended mode case or the address on the "further" MAP's subnet

Yes but this "further" contradicts what you specify as the MAP option with the shortest
distance will get picked up by the MN. I am saying that be cause if you have 3 fixed MAP one
below the other then you do not have any measure to pick the "further" one that you say...it
can be ANY of the above the first one.

If you are not clear in the spec on that I have to assume the shortest one wins....

>         the MR's LCoA is sent directly to the HA.

No...there are two things that MUST be done here as far as the MR/MAP is concerned (much like
any HMIPv6 node)

  1. register with a fixed MAP.  This is the MAP_BU that you mentioned. Fine
   2. Send a BU back to its HA to inform it where it is. HOW ABOUT THAT????

>         be received by the MR's HA, unless the MR's HA = MN HA.

No no no no no....the packets sent by the HA of the MN were originally tunneled to the alt-CoA
of the MN. But what was it at the time ????
It was the IP addr (LCoA) of the MR/MAP before it flew of... As a result because the MR/MAP has
gone away the packets MUST be intercepted naturally (base mobility here) by the HA of the
MR/MAP....

>         CoA if no other (further) MAPs exist. OK ?

Right ...there are no other further MAPs, so it is MR's LCoA...but this it's home addr at the
home domain...so what more natural for any packets that arrive to that address when the MR is
not there to be intercepted and retunneled by its HA......????????

>         => Then the MR's HA should never receive the MN's traffic.

It is not that MR's HA will receive MN's traffic but it will have to intercept it and retunnel
to the RCoA of the MR....

>         we'lll change it to reflect what I just told you.

It does not say it....but it does not have to ....it is natural logic as soon as the MR goes
away and packets are coming to its LCoA at its home domain...

>         => NO. It's the LCoA of the MR.The one advertised in its

>         The one that belongs to the visited domain and not the

Yes and I agreee TOTALY with you...what is that LCoA at the home domain of the MR...?????

>         scenario you're describing.

Theo

UCL / Mobile Systems