Subject: RE: rfc2292bis: interaction with home address option

From: Richard Draves <[email-masked]>
Date: Wed, 24 May 2000 16:34:34 -0700

> >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.

Exactly.

The situations where having the app use a "this is short-lived" socket
option make the most sense are when the correspondent's binding cache is
likely to be ineffective, like non-persistent HTTP connections or DNS (UDP
or TCP) queries. 

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: Thomas Eklund <[email-masked]>
Date: Thu, 25 May 2000 14:20:16 +0200

Hi Steve,
> It would also be good if common apps made it very easy for the user to
> override the default behavior and force use of the COA address as the
> source, for those cases when the user (a) knows that the 
> destination is
> "close" and (b) doesn't plan to move before the session ends 
> or doesn't
> care if a move breaks the session.

How can you decide that?
Seems to me that the only sessions that fit into that category is the local
services like "UDP based sessions" to DNS etc...
 
I can imagine that sessions that are close could use a special sitelocal src
address...

I see this as beeing part of the anycast addressing that is yet to be solved
within a site and global scope...
I assume that the routing protocol has to distribute the site local info
within the site in order to make the anycasting work...
So perhaps define the anycast model and see how you can use a special site
local src address for anycast services...

Regards
  Thomas

---

From: Thomas Eklund <[email-masked]>
Date: Thu, 25 May 2000 14:52:38 +0200

Hi Steve and others,
just a short comment.

> -----Original Message-----
> From: Steve Deering [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2000 10:23 PM
> To: Richard Draves
> Cc: [email-masked]'; [email-masked]
> Subject: RE: rfc2292bis: interaction with home address option
> 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 breaks much of the nice feature with route optimazation and we are back
to the less nice mobile 
ipv4 solution... And I dont see why it is needed?
This would only eat up more of the operators available network bandwidth ...

What is location privacy - I said it on the mobile IP list and I say it
again that I would argue that it is not something we want...

If you are  willing to let the packet take a longer route via its home
network what do you achieve...? 

This also leads to Itojun question when a CN wanted to know the CoA of the
mobile node... Why do the application (and the BSD API) need to have any
knowledge about this...? And if the API dont have any way to get the CoA
then this would not be a problem and the home address option would work as
its suppose to work (using the HA) - to hide everything to the transport
layers...

In ipv6 you have the address diveded into two parts and it is only of
interest to a "spoofer" what your lower 64 bits are (i.e. your interface id
or EUI-64)..
And there is a draft how you add privacy to the interface part
(http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-01.t
xt*) 
That means that you cant be tracked... Eventhough a spoofer sees where the
packets comes from he cant reveil from who it is originated...  In other
words there are already a solution to the privacy issue... So the privacy
issue is not an valid for having the BU turned off...  this solves the
privacy for the user but do you ever want to have location privacy??

 Thomas Eklund

---

From: Richard Draves <[email-masked]>
Date: Tue, 30 May 2000 13:59:14 -0700

>    Assuming you send a binding-update in the SYN, then 
> communication using the
>    home address will be relatively efficient - just a little 
> more overhead in
>    the packets, but no extra packets and no packets going 
> through the home
>    agent.
>    
> => even the idea of a binding-update in the SYN seems nice 
> this will not
> work like this a the real word because the binding-update must be
> authentic ie a security association must be established before.
> If you use IKE with certificates then this can be more expensive than
> to go through the tunnel and can add a delay before the connection
> set up.

Well, that's a good point - I'd forgotten about the security overhead of
protecting the binding update. But I still think the default should be for a
mobile node to use a home address instead of a care-of address, unless there
is app or user guidance (like the "this is a short-lived socket" option).

Rich