Subject: RE: rfc2292bis: interaction with home address option

From: Richard Draves <[email-masked]>
Date: Wed, 24 May 2000 13:05:12 -0700

> >Considering the case of a mobile node initiating a TCP 
> connection to a
> >global address, with a choice of a global home address and a 
> global care-of
> >address, I think the desirable default behavior to use the 
> global home
> >address for the TCP endpoint and insert the home address 
> option (and a
> >binding-update option in the SYN). I think this is the 
> desirable default
> >even if the care-of address and the destination address appear to be
> >topologically closer than the home address and the 
> destination address.
> 
> I agree.  That way the TCP won't break if and when the mobile moves,
> which is one of the main reasons for doing mobile IP in the 
> first place.
> 
> 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.

I can imagine having a "this is short-lived" socket option, and if the app
sets the option then the stack would prefer care-of addresses over home
addresses instead of the other way around. This is the app telling the stack
that your condition (b) holds. I don't see the importance of condition (a).

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.

The main exception would be when you are dealing with a server that handles
lots of short-lived connections - it's binding cache might not work well. So
for your short-lived connections to such a server, you'd want to use your
care-of address instead of your home address.

If this option is going to be useful, it needs to be something that the app
can decide - having UI for this would not be good.

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 13:22:38 -0700

At 1:05 PM -0700 5/24/00, Richard Draves wrote:
> > destination is "close" and (b) doesn't plan to move before the session
> > ends or doesn't care if a move breaks the session.
>
>that your condition (b) holds.

That sounds like a promising idea.

> I don't see the importance of condition (a).

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.

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.

I'm not adamant about this, but I think it's worth considering.

>can decide - having UI for this would not be good.

Where the app can make a good enough decision, it should.  But I think
there should also be a way for users (perhaps only geek users) to override.

Steve

---

From: [email-masked]
Date: Thu, 25 May 2000 10:14:39 +0900

>the packets, but no extra packets and no packets going through the home

	Mobile-ip6 requires only one thing to correspondent node:
	honor home address option.
	Spec does not require every correspondent node to have binding cache,
	so binding update in SYN may not work and result in triangle routing.
	Therefore, I still think this is valuable for mobile node to be able
	to use care-of as TCP/UDP source address, for short-lived sessions.
	For me, short-lived sessions include:
	- local services in remote site the mobile node is visiting
	  access to web cache in remote site it visits, access to printer
	- use ubiquitous services in remote site (DNS)

>care-of address instead of your home address.

	I suspect that busy web servers will not have (or will not use)
	the binding cache.  The server will not be able to maintain it.

itojun

---

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

In your previous mail you wrote:

=> 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.
 Then your argument is not as good as we'd like and I agree with the
(missing) rationate of "correspondent detection":
   In particular, the mobile node SHOULD return a
   Binding Update in response to receiving a packet that meets all of
   the following tests:
    -  The packet was tunneled using IPv6 encapsulation.
    - ... (some sanity checks on outer and inner addresses)

   
=> is my answer (a getsockopt() which returned the selected address in the
general case and the (suitable) care-of address in the mobile node case)
enough for you?

Regards

[email-masked]