>> 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 mob
>I can imagine having a "this is short-lived" socket option, and if the app
>sets the option then the stack would prefer care-of addresses over home
>addresses instead of the other way around. This is the app telling the stack
>that your condition (b) holds. I don't see the importance of conditio
> >But if the binding cache on the local server is working well
> enough to
> >maintain the binding, and the mobile node sends a binding-update
> >proactively with its SYN, then the home agent won't be needed. This
> >should be the common case when the mobile node is initiating the
> >communicati
At 2:18 PM -0700 5/24/00, Richard Draves wrote:
>This is a good idea, but I don't recall any text in the mobility spec that
>talks about the mobile sending packets to the correspondent by tunneling to
>the home agent. (The tunneling right now is in the other direction.) I think
>it would be a simp
At 4:32 PM -0400 5/24/00, Bill Sommerfeld wrote:
> > 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
> I presume another UI option that would be desirable on a
> mobile node is
> a "privacy" switch that prevents binding updates from being sent, and
> also tunnels mobile->correspondent packets via the home agent, so as
> not to reveal the current (network) location to correspondents. When
> oper
> 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 uppe
> >Considering the case of a mobile node initiating a TCP
> connection to a
> >global address, with a choice of a global home address and a
> global care-of
> >address, I think the desirable default behavior to use the
> global home
> >address for the TCP endpoint and insert the home address
>
At 1:05 PM -0700 5/24/00, Richard Draves wrote:
> > It would also be good if common apps made it very easy for the user to
> > override the default behavior and force use of the COA address as the
> > source, for those cases when the user (a) knows that the
> > destination is "close" and (b) does
At 11:16 AM -0700 5/24/00, Richard Draves wrote:
>The mobility draft has at various points or times talked about swapping the
>source address in the IPv6 header and the address in the home address
>option. This is OK conceptually and I understand that some implementations
>actually work that way.
Some comments on this thread...
I agree that by default applications should see home addresses not care-of
addresses. This is especially true on correspondent nodes.
The mobility draft has at various points or times talked about swapping the
source address in the IPv6 header and the address in t
> 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
>> 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
>> - then, how can we get care-of address of the peer?
>> (1) new IPV6_RECVxx in rfc2292 advanced API?
>> (2) new system call? -> unacceptable
>Seems like first we should decide whether it is a requirement of the API
>to be able to return this information.
>Then we can decide what the m
> For example, some UDP based services (IKE for example), need to know
> the actual destination address that was used in the incoming UDP
> packet. In IPv4, the only way to get this was to enable raw mode and
> dig it out from the packet. I guess for this special need, the packet
> information of
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)
> - 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.
home address
Do you have an example application that may need to see the COA?
> - which address should recvfrom(
>>- 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
At 5:39 PM +0900 5/24/00, [EMAIL PROTECTED] wrote:
>when a node A received packet from mobile node B:
>packet will carry home address of B in home address option (destination
>options header, and care-of address in IPv6 source
>- which address should getpeername() return? home address, or care-of
thanks Itojun..
/jim
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 r
> ?? with RFC2292 IPv6 raw socket, this is not possible.
> (if you pass IPv6 header to the userland, that is not RFC2292
> conformant)
... promts me to make a query concerning dual IPv4/IPv6 stacks: has
anyone given any thoughts about mapping IPv4 into RFC2292 (+bis)?
One shou
Just some quick answers about what our code would do now...
> when a node A received packet from mobile node B:
> packet will carry home address of B in home address option (destination
> options header, and care-of address in IPv6 source
> - which address should getpeername() return? home addre
>Just some quick answers about what our code would do now...
>> - then, how can we get care-of address of the peer?
>receive UDP in raw mode and dig in? :) (however, the raw mode is hard
>to apply to TCP...)
?? with RFC2292 IPv6 raw socket, this is not possible.
(if you pass IPv6
Hello, while thinking about interaction between mobile-ip6 and
BSD APIs, I came up with the following questions. I still do not
have the answer. If you have any working practice I would like
to know that. They can be related to future revisions of rfc2292bis.
it
24 matches
Mail list logo
