>>- which address should getpeername() return? home address, or care-of?
>> home address sounds like a good default pick, however, some apps
>> may need to look at care-of.
>Itojun,
>On the correspondent node, getpeername() should return the home address
>of the mobile node. This is so most apps can be oblivious to the mobility
>of the node to which they are speaking.
>Can you give some examples of why an app on the correspondent node would
>want or need to know the current care-of address of its peer?
>>- which address should recvfrom() return?
>> ditto.
>The home address.
>>- can we get home address option in IPV6_RECVDSTOPTS?
>> it seems like so. it will have home address of B, not care-of.
>If you really need to receive both addresses for some reason, the care-of
>address is the one that should be obtainable only via IPV6_RECVDSTOPTS.
>Logically, the IP layer in the correspondent host should swap the received
>home address and care-of address before passing the packet to an upper
>layer.
Yes, I agree that by default only home address should be visible,
so getpeername() and recvfrom() should see home address only.
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.
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.
>>when a mobile node A sends packet to a node B:
>>A may want to control the use of mobile-ip6. examples: (1) if A would like
>>to talk to ubiquitous services like DNS, A may want to use care-of address,
>>not the home address. (2) IKE (to establish key for mobile-ip6) requires it.
>>- how can we avoid use of home address? 1-bit flag in setsockopt?
>This is just another example of the source-address selection problem (as
>discussed in Rich's draft). When initiating communication, the mobile
>host must select one of its valid addresses to use as source address.
>The default behavior, if the application or user doesn't care, would be
>to use the home address (or one of the home addresses, if there are
>more than one). But an application, such as the ones you mentioned,
>can choose to use a different source address, i.e., the temporary
>care-of address. We should already have whatever API function is needed
>for the app to specify the source address, so no new flags ought to be
>needed.
Do you suggest that bind(2) should affect the use of home address
option? 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.
Interaction with IPV6_PKTINFO still confuses me. I'm unsure about
interaction between IPV6_PKTINFO and bind(2) if we use both (it is
not documented in 2292bis-01). I'm even more unsure about its
interaction with mobile-ip6.
Another example of confusion: interface selection. We have so many
ways to specify outgoing interface, or scope zone, when we throw packet
to outside:
1. sin6_scope_id field in sendto(2)/sendmsg(2)
2. sin6_scope_id field in connect(2)
3. sin6_scope_id field in bind(2)
4. IPV6_PKTINFO sticky option
5. IPV6_PKTINFO on sendmsg(2)
(3) to (5) specify source, but if we use link-local source they
would affect the outgoing interface selection.
we know (1) overrides (2) in IPv4. other interactions are not defined.
FYI, KAME uses the following order (we know this is not in standrd,
but this was the best we could come up with):
- IPV6_PKTINFO on sendmsg(2) is the strongest
- IPV6_PKTINFO on sticky option
- address specified by basic API on transmission (one-time option, like
sendto)
- address put into pcb struct (sticky, like bind/connect) is the weakest
itojun
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
