>> The best example is IKE traffic used for mobile-ip6 IPsec key.
>I don't understand what the requirements are for this case.
>On a correspondent IKE can just use the home address of the mobile during
>the IKE exchange, right? (The packets will go to the home agent and
>be tunneled to be mobile node.)
>Is this an issue for the IKE exchange between the home agent and the MN?
sorry again I was confused. IKE traffic for mobile-ip6 key does
not carry home address option. this is mobile node who needs to use
care-of as source. correspondent node do not need tricks.
(mobile-ipv6-12 10.2)
>> 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:
>You can do it even without an added flag.
>If the application has bound to a specific IP address (and not in6addr_any)
>then that address will be used as the source address (and for TCP connections
>there is an implicit "binding" that occurs when the SYN is sent or received -
>nothing new here).
>Thus if app bound (explictly or implicitly) to a home address and the MN
>is not at home, the home address option would be added by the stack.
>Otherwise there is no need add it.
>This does require that the stack distinguishes between its home
>address(es) and COA(s), but I suspect it needs to make that
>distinction in any case.
I meant kernel internal flag by "home address flag", which may or may
not be exposed through the API.
kernel needs to somehow distinguish its home address from its care-of.
I think my wording was not clear enough.
>> 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
>Should I just put this order as the recommended order in 2292bis?
if there's no conflicting opinion on this, I'm happy with that.
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]
--------------------------------------------------------------------
