> The best example is IKE traffic used for mobile-ip6 IPsec key.
Itojun,
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?
> 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.
> 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.
My assumptions have always been that IPV6_PKTINFO has the same semantics as
bind() in this respect. I guess it would make sense to make that explicit in
2292bis.
> 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?
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
