Subject: [nemo] Visiting Nodes

From: Eranga Perera <[email-masked]>
Date: Thu, 26 Feb 2004 22:15:18 +1100 (EST)

Hi,
Thanks for the replies. Thought I'll express my humble opinion in one go!

I agree with Maria and Pascal in the sense that if a commuter obtains
connectivity via a MR then his/her device will be operating in a manner
similar to a LFN. But shouldn't our objective be to enable these nodes to
run any application not just browse the web. How about accessing VPNs?

Alex,
A non MIPv6 node sure enough would loose the connection when hopping from
a bus to a train. But say for example a commuter needs to synchonize his
calendar on his PDA with the PC in his office. If we assume that visiting
nodes without MIPv6 capabilities are like LFNs then such applications
cannot be supported unless we take care of the security issues. So isn't
it necessary to give emphasis to visiting nodes without MIPv6 capabilities
and try to solve these issues. Basically if these visiting nodes have
permanent IP addresses then how does NEMO protocol handle such nodes -
bidirectional tunneling via double Home Agents ?

Or can we safely  assume that all viising nodes will have MIPv6
capabilities and not address the above issues? Are all future devices
going to be embeddded with MIPv6?? I guess this is a point to ponder!

Sorry if I've misinterpreted something.

Regards,
Eranga

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 Feb 2004 14:37:47 -0000

> 
> 	On the other hand, IMHO it is very interesting the topic of practical
> usage scenarios in which network mobility could be involved. I mean,
> what is more likely to occur, nodes with ongoing communications that
> enters in a train or nodes that enter in a train and start browsing the
> Internet, for example?

Interesting question. 

I think it's the chicken and the egg problem... The usage of the web is mostly a pull model because of limitations of IPv4, NAT and so on, not because it's the best way to do things. There's a lot of P2P applications that would benefit from a direct and always on connectivity. You can not just say that the next killer applications will be a pull model just because that was the only way in the past...

If your visitor has a few presence based apps (or some proprietary Instant Messaging for that matter), he will have to reconnect to the each and every one of those apps each time he moves to a different bus. Lots of traffic, very low value. I wonder how many such users the IM can sustain. If he supports IP mobility and registers to IM using a Home Address, that's a different story. Also, this preserves the privacy of the location of the user.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 Feb 2004 14:37:47 -0000

Interesting question. 

Pascal

---

From: Miklós Aurél Rónai (IJ/ETH)<[email-masked]>
Date: Thu, 26 Feb 2004 15:47:47 +0100

Hi Carlos,

I would like to reflect shortly on the paragraph below.

> 	On the other hand, IMHO it is very interesting the 
> topic of practical usage scenarios in which network mobility 
> could be involved. I mean, what is more likely to occur, 
> nodes with ongoing communications that enters in a train or 
> nodes that enter in a train and start browsing the Internet, 
> for example?

I think that the scenario where people enter a train and starts web browsing is more likely today ... but tomorrow where we will be able to make video conferences with our handhelds it will be more typical that we enter the metro or the train with ongoing communications. I am afraid that DHCPv6 or IPv6 stateless autoconfiguration are not able to handle movements of mobile nodes with ongoing transmissions.

/Miklos

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.