At 1:27 AM +0900 5/25/00, [EMAIL PROTECTED] wrote:
> Your suggestion,
> - Swapping received home address option and care-of (in ip6 header)
> in ip6 layer and
> - Present care-of address in IPV6_RECVDSTOPTS
> is a good candidate (this was one of scenario in my mind), however, we
> need to document it at least. Otherwise we will get low portability.
I thought that was documented in the Mobile IPv6 spec (but it's been a
long time since I read it, so I may just be imagining what is supposed
to be there.)
> There always are certain applications that needs to peek, or use
> care-of address. From my limited experience "transparent mobility"
> is not usually useful, and we need "mobility awareness" in many cases.
> The best example is IKE traffic used for mobile-ip6 IPsec key.
Clearly, the apps on the mobile host itself often need to be aware of
their own mobility. But why should apps on the correspondent node have
to know anything? And if they do, they should be informed by via their
application-layer protocols, not by polling the IP layer about each peer
to see if it happens to be mobile.
> Do you suggest that bind(2) should affect the use of home address
> option?
bind should affect the choice of source address. The IP layer is
expected to know which of its addresses are home address. Sending a
packet on a socket that is bound to a home address, when away from home,
should cause the home address option to be added to the packet before
transmission. (Note: need to worry about PMTU discovery consequences of
inserting options without application's knowledge.)
> I'm not 100% sure if bind(2) does enough thing for us.
> If we can assume that we have "home address flag" on every interface
> address we have, then yes, we can do this:
> - If we are in home network, use whatever the user have specified with
> bind(2).
> - If we are in remote network,
> - If the address specified by bind(2) is marked as home address,
> use it with mobile-ip6 dance (attach home address option,
> use some care-of address in IPv6 source)
> - If the address is marked as non-home address, emit packet
> without mobile-ip6.
> If we take this route, we need a portable way to identify which
> interface address is home address, and which are not. this should be
> documented somewhere in 2292bis.
Yes, the IP layer certainly needs to know which of its addresses are home
addresses. I've talked about this a couple times at WG meetings, e.g., see
http://playground.sun.com/ipng/presentations/Sep99/PDF/deering-plugnplay.PDF.
One approach is to have some sort of user interface (command, button, or
whatever is appropriate for the type of device) to tell a node "You are
now on your home subnet. Remember these addresses." Another approach
might be to have a node look up its own DNS name (which it keeps stored
in non-volatile memory) and consider any addresses that come back that
don't belong to the currently attached subnet(s) to be its home addresses.
This definitely needs to be thought through and written down.
I don't have quick answers to the rest of your questions.
Steve
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
