Subject: RE: rfc2292bis: interaction with home address option

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

Some comments on this thread...

I agree that by default applications should see home addresses not care-of
addresses. This is especially true on correspondent nodes.

The mobility draft has at various points or times talked about swapping the
source address in the IPv6 header and the address in the home address
option. This is OK conceptually and I understand that some implementations
actually work that way. But at least in our implementation, we treat packet
data as read-only. I would not like to see specifications that assumed the
swapping really does happen.

There is a source address selection problem on mobile nodes: when do you use
a home address vs a care-of address? The default source address selection
rules as currently specified don't always produce the desired results.
(There aren't any special rules or provisions for mobility.)

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.

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 11:30:12 -0700

>swapping really does happen.

There is precedent for address swapping while a packet is in transit:
the Routing Header works that way.  Granted, no swapping happens at
the source or final destination node, in that case.

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

Steve

---

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

In your previous mail you wrote:

=> I understand your concern but:
 - routing header processing already specifies a real swap (then if home
   agent option has the symmetrical effect it may use the same way to do it)
 - current specifications don't say if I (real swap) or you (don't swap
   data but only swap pointers) do the right thing and only one is correct
   (because AH won't give the same message digest in both cases).
This must be fixed!

=> this (no rule/provision for mobility) is a well-known open issue
in your I-D about source address selection. This thread will help us
to see what we need for it...

   binding-update option in the SYN).

=> I agree

   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.
   
=> this is less clear, for instance if you use mobility IPv6 in a nomadic
case (ie. you are in visit somewhere, you'd like to use the home facility
(with your hostname, addresses, ...) and the local facility (the local
printer for instance) and you'll shutdown your box before moving) then
you'd like to use the care-of address for local communications.
 If you are moving rather fast in a cellular network you'd never want
to use the care-of address (the opposite case).
 I believe we need a rule for local usage of the care-of with some levels
of locallity (node / link / site ?) and give the choice/control to users.

Regards

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 30 May 2000 22:07:49 -0700 (PDT)

>    (because AH won't give the same message digest in both cases).

In terms of the API (and IP_RECVDSTOPTS in particular) we can presumably
satisfy both of you by saying that the content of the IP_RECVDSTOPTS ancillary
data item, when it contains is a home address option, has the address
field in the home address option set to the care of address i.e. the
source address of the packet when it arrived.

This doesn't require modifying the packet when it arrived (Rich's concern
as I understand it) - instead it requires some care when constructing
the IP_RECVDSTOPTS ancillary data item.
Of course, implementations that process the home address option by
doing a swap have less work to perform when constructing the ancillary data
item.

Should we put this in rfc2292bis?

   Erik

---

From: [email-masked]
Date: Wed, 31 May 2000 15:22:06 +0900

>Should we put this in rfc2292bis?

	I personally think the above proposal is okay for me, and solves
	my original question.
	as passing home address option as-is does not add any information
	at all (you can get the home address by getpeername) it is better.
	(it is a bit twisted, I admit)

itojun

---

From: Markku Savela <[email-masked]>
Date: Wed, 31 May 2000 10:39:08 +0300 (EET DST)

> From: [email-masked]

> 	(it is a bit twisted, I admit)

Too many of these "twists" in specification is worrysome. I can go
with the "swap" specification, but it still feels itchy to read "get
destination options", but hey, remember you are not getting the true
original destination options, but a twisted version ...

But, as I have not been involved implementing that thing, it is just
the feeling, no serious objection from me. I assume other people know
what they do.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 31 May 2000 10:07:21 +0200

=> the API is fine but the mobility draft doesn't specify how to compute
the AH message digest (mandatory if there is a binding update too).

=> It should be in the mobility RFC but if it is not in it then RFC 2292bis
is a good place.
Note that in fact there is no real usage for it for common correspondents
(ie. this has a low priority).

Thanks