> => the draft proposes a solution for application knowledge
> (socket option)
> but not user knowledge (or do you suggest to add to every applications
> some arguments and code in order to control address
> selections, I believe
> this is not your intent, then clearly your draft needs something...)
No, my belief is that few applications will find it necessary/desirable to
optimize their use in mobility situations and use a socket option to request
a care-of source address instead of a home address.
MIPv6 will avoid the dog-leg routing through the home agent in normal use,
when a mobile node initiates a connection using its home address. You
include the binding update in the first packet you send (eg, the TCP SYN) to
the correspondent. This is what the Lancaster implementation of mobility for
MSR IPv6 does.
So using the home address by default is really not that inefficient.
There is one detail here: we don't implement IKE (although we do implement
IPsec and will protect the mobility options with IPsec) and so I don't know
if the IKE negotiation of SAs to protect that first binding-update will
happen without going through the home agent. But this should be possible.
> PS: can you explain how the control is done in your implementation?
> PPS: perhaps an API for policy table control should be specified??
I don't see the need to standardize an API for policy table control. I view
the policy table in my draft as conceptual - implementations might have
various different ways of specifying policy. So it would be hard to
standardize APIs for controlling it.
Rich
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
