In your previous mail you wrote:
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?
> home address sounds like a good default pick, however, some apps
> may need to look at care-of.
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.
=> I agree!
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?
=> I know no example but there is at least one (IKE) on the mobile node
which would need to know the current care-of 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.
=> Logically but not (yet?) written down in the IPv6 mobility document!
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.
=> Itojun's concern a bit different, he asked how the application can get
the care-of address. Today racoon (KAME IKE deamon) does:
- open a new UDP socket
- connect it to the destination
- get the selected source address by getsockname()
- use it (ie in bind() system call) for IKE exchange with the remote party
with security processing disabled (ie. IKE has its own protection).
I have changed it into:
- open a new UDP socket
- connect it to the destination
- get the selected real source address by a new getsockopt() which gives
the care-of address (not the home address) on a mobile node in visit
and the same answer than getsockname() in other cases.
And for IKE exchange I disable mobility processing (ie home address stuff)
and security processing.
Then only things I use are:
- interaction between source selection and mobility (ie use the home address)
- a way to get the current care-of address
Regards
[EMAIL PROTECTED]
PS: the rationate (according to draft-ietf-mobileip-ipv6-12.txt) again:
- The mobile node MUST use its care-of address as the Source
Address of all packets it sends as part of the key management
protocol (without use of Mobile IP for these packets, as
suggested in Section 10.1).
Example: the mobile node boots in visit and needs to send an
authenticated binding update for home registration to the home agent.
(boots -> no established security association, authenticated -> needs
to setup a security association before, home registration -> the home agent
doesn't know the binding and can't reply to the home address)
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
