Subject: [mobile-ip] wither home address destination option?

From: Michael Thomas <[email-masked]>
Date: Sun, 4 Mar 2001 15:27:49 -0800 (PST)

Well, at least maybe a close re-examination of it? 

In the last week I've managed to stumble on two
serious side effects of the home address
destination option. The first was when I realized
that I made a mistake in my rsvp/mip draft with my
general hope that fixing a problem with rsvp would
help mipv6 as well. In particular, my mistake was
in expecting that the reservation could heal
locally with a different kind of reservation type.
This turns out to not be the case, and it was
startlingly obvious after I thought about it a
bit: when you change care of addresses, _all_ of
the routers who are party to the reservation need
to get updated filterspecs with the new care of
address.

I believe that there is a draft (Shen) which
suggests using the home address destination option
as part of the flow key, but I'm afraid that that
is going to be terribly slow since chasing down
variable headers is not terribly efficient for
routers.

Note that the root cause of this is the we're
assuming that the care of address must be placed
as the source address, not the home address. In
fact, if the home address were used instead of
the care of address, it would produce the desired
result of local healing at the join point of
the reservation.

The second thing I found -- and I think far more
devestating -- is the observation of what would
happen to hosts behind a mobile router. I've
mentioned that I think that it is untenable for
hosts behind a mobile router to be knowledgeable
of the _mobile router's_ mobility. If nothing
else, otherwise usable fixed line devices -- like
oh say everybody's PC -- would cease to work on a
boat or train or plane which had a nice mobile
router connecting it up to the Internet. The thing
that really opened my eyes is when a coworker
mentioned that if the hosts behind the mobile
router weren't mobile aware, they wouldn't be
putting a home address option in, and would likely
fail RPF checks. Ugh.

In both of these cases doing the natural thing of
putting the home address in the IP header would
solve these unfortunate side effects. Reading the
current draft, as far as I can tell the
recommendation for using the destination option
seems to have to main rationale:

1) RPF checks
2) Multicast works better

RPF, IMO, is hardly sacrosanct: there is a well
known failure mode of RPF which has to do with
asynchronous routes which is sometimes tickled by
multihomed hosts. I'm coming to the conclusion
that this may be another limitation of RFP which
if you consider it is not entirely surprising:
mobility isn't entirely dissimilar to multihoming.
RPF's main attraction is that it's trivial for
routers to perform, however there are potentially
other means of doing source filtering -- so called
ACL's could be enabled to perform a similar
function.

The Multicast angle is new to me, so I'm hoping
that maybe somebody can explain what the issues
are. However it seems that at least in some cases
it would be whole lot more natural to use the home
address as the IP source address. 

	   Mike, who knows worm cans
	    when he sees them

---

From: <[email-masked]>
Date: Sun, 4 Mar 2001 19:38:39 -0800 (PST)

Hello,

Connectathon network interoperability testing event is taking place in San
Jose, California this week. In addition to Mobile IP testing, the event
features a number of mobile and wireless related presentations which are open
to public:

Monday 5th March 

  2:00 - 2:30 TTCN-3 Test Environment in IPv6 Test - Peter Kremer (Ericsson)
  2:30 - 3:00 Mobile IPv6 TAHI Conformance Test - Yukiyo Akisada (TAHI) 
  3:00 - 3:30 Lessons from implementing Mobile IPv4/Mobile Node - Yoshiyuki
Tsuda (Toshiba) 
  3:30 - 3:45 Mobile IP limited private Address Support Implementation -
Samita Chakrabarti (Sun Microsystems) 

Tuesday 6th March 

  4:00 - 4:30 Wireless Without a Net - Why I lose sleep over 802.11b -
Christopher Hertel (University of Minnesota) 

Wednesday 7th March 

  4:00 - 4:30 Mobile IPv6 interaction issues with IPsec - Carl Williams, Mohan
Parthasarathy, Alper Yegin (Sun Microsystems)
  4:30 - 5:00 The Mobile IPv6 implementation on the InternetCAR project -
Ryuji Wakikawa (Keio University) 

For location and more information check out www.cthon.org

Alper E. Yegin
Mobile IP Technology Coordinator
Connectathon 2001