In your previous mail you wrote:

        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.

=> I have both!

   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.

=> home address with a getsockopt() (or a new system call) which returns
the real destination address. Same for getsockname() because IKE needs
a way to know the real source address, ie ID-12:
    -  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).
For the correspondent node things should be more transparent but:
 - home agents are correspondents
 - symetry argument
then I'd like to get both getsockopt() in the new standard, of course
results should be sockaddr_in6 structures and be the same than from
`genuine system calls when there is no mobility stuff.

   - which address should recvfrom() return?
        ditto.

=> same problem but it is enough to have a getsockopt() for connected/bound
sockets because the mobility stuff uses addresses only. The answer is
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 the new I-D or RFC is clear enough about processing of home address
option processing then we'll know the answer. If per instance it asks for
an address swap (my favourite) then the destination address in the header
will be the home address and the address in the option the care-of,
recvfrom() will return the home address (good) and the care-of will be
accessible with IPV6_RECVDSTOPTS (good again). As a side effect we'll
know how to compute the AH message digest (:-).

   - then, how can we get care-of address of the peer?
        (1) new IPV6_RECVxx in rfc2292 advanced API?
        (2) new system call? -> unacceptable
   
   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.

=> (2) IKE is why I've already added a getsockopt() for this.
For (1) I have a configuration flag in the mobility management tool
in order to consider local nodes (ie nodes on the same link/sharing
same prefixes) as correspondents or not:
 - with the first option all new communications will go through the home
   (remote) agent
 - with the second option open connections with local nodes will be
   broken by movements.
There is no good choice then users can say what they like. I believe
you'd like a way to override the first choice for "smart" applications
(this is fine for me).

   - how can we avoid use of home address?  1-bit flag in setsockopt?

=> see above

   - what is the relationship/interaction with IPV6_PKTINFO?

=> I believe only special getsockopt() should look at what really happens
with mobility stuff. Other parts of the API should be as transparent as
possible.

Regards

[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to