Subject: RE: rfc2292bis: interaction with home address option

From: Richard Draves <[email-masked]>
Date: Wed, 24 May 2000 14:18:33 -0700

> I presume another UI option that would be desirable on a 
> mobile node is
> a "privacy" switch that prevents binding updates from being sent, and
> also tunnels mobile->correspondent packets via the home agent, so as
> not to reveal the current (network) location to correspondents.  When
> operating in such a mode, the performance impact of having 
> all of one's
> packets dogleg-routed through the home agent might be very 
> undesirable,
> especially when the mobile and correspondent are on one continent and
> the home agent is on another.

This is a good idea, but I don't recall any text in the mobility spec that
talks about the mobile sending packets to the correspondent by tunneling to
the home agent. (The tunneling right now is in the other direction.) I think
it would be a simple addition.

> Another possible reason for user-specified use of the COA 
> address instead
> of the home address is to be able to communicate even when 
> the the user's
> home agent(s) are down or unreachable for whatever reason.

Certainly, I would hate to be in a position where I can't talk to a local
service because my home agent happens be to unreachable at the moment. But
if the binding cache on the local server is working well enough to maintain
the binding, and the mobile node sends a binding-update proactively with its
SYN, then the home agent won't be needed. This should be the common case
when the mobile node is initiating the communication.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Wed, 24 May 2000 14:46:38 -0700

>it would be a simple addition.

I recall this issue coming up for the IPv4 version of mobile IP, and assumed
it would apply just a much to IPv6.  I really must start reading more specs,
rather than just assuming they contain what they ought to contain.  :-)

I trust the Mobile IPv6 spec authors are on this mailing list and will
enlighten us at some point.

>But if the binding cache on the local server is working well enough to
>maintain the binding, and the mobile node sends a binding-update
>proactively with its SYN, then the home agent won't be needed. This
>should be the common case when the mobile node is initiating the
>communication.

A-ha, now I get it.  Yes, that would work, subject to the correspondent's
willingness and ability to store the binding, as you mentioned before.
But I would expect (not knowing for sure because I haven't read the spec)
that there is no obligation on the correspondent to store all, or even any,
of the bindings it receives.  Obviously, we hope most correspondents will
do the helpful thing, but particlarly dumb, lazy, or overworked ones
would be within their rights to ignore binding updates and always just
send via the home agent.

But I guess the point you were making was: if most correspondents do the
right thing, there will be many fewer occasions when a user-override
would be necessary.  That I can agree with.

Steve

---

From: Jim Bound <[email-masked]>
Date: Thu, 25 May 2000 23:17:05 -0400

>when the mobile node is initiating the communication.

This has been my implementation assumption and design center and the
deployment model for MIPv6.  In fact I think when the coresponding app
speaks the mobile node this should be the default given the binding
update is current. 

/jim

---

From: Francis Dupont <[email-masked]>
Date: Sat, 27 May 2000 18:50:35 +0200

=> this kind of reversed tunnelling can be used for multicast packets
sent by the mobile node (see section 10.18) then a half of the text is
already there...

   
=> as I have already explained this (proactive BU with SYN) is not a good
idea and it is better to rely on traffic in the HA->MN tunnel (which is
the traffic which has to "pay" for no binding).

Regards

[email-masked]