> - 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() return?
>       ditto.

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.

We've had some discussion a while back on the topic to what extent
the protocol stack must remove options and not pass them up
to the application. The main issue back then was the jumbogram option.
I think we decided to leave this implementation defined i.e. the stack
might choose to remove the jumbogram option or leave it in place.

So I think in general 2292bis doesn't state (clarly) what happens to
hbh and destination options which the stack actually does some
processing on - are they passed to the application or not; and
if they are passed to the application must the stack leave the option
content exactly in the form it arrived on the wire.

> - 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 mechanism should be.

> 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.
> - how can we avoid use of home address?  1-bit flag in setsockopt?
> - what is the relationship/interaction with IPV6_PKTINFO?

Just to clarify: are you talking about the case when A wants to use
A's COA as the source instead of A's home address?

I assume the bind() socket call can be used to specify the source address
to use.

   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]
--------------------------------------------------------------------

Reply via email to