In your previous mail you wrote:
> => 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.
=> I disagree, there are some usages of mobility where random applications
should use a care-of address if it is closed enough to the destination,
and some where its depends on both the application and the proximity.
Your proposal is simply too inflexible and I don't understand why
we can get a policy per user, environment, ... and not a flag.
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.
=> this has just a very little drawback, you assume there is already a
security association settled before by the totaly user-friendly and efficient
tool named IKE (:-)... I'd like to see what the Lancaster implementation
will do now with the (mandatory) security.
So using the home address by default is really not that inefficient.
=> it is always inefficient and some times unnecessary. Mobility
is supposed to be one of the bug advantages of IPv6, don't restrict it
to some contexts please.
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.
=> I have both IKE and mobility working together then I can answer.
IKE should use the care-of address and MUST use it for the first home
registration when the mobile is booted in visit. But IKE is a special
application (it has similar constraints for IPsec processing) then
what IKE needs a getsockname() clone which returns the care-of address
in place of the official (== home) address bound to the socket, ie.
this new socket option should simulate the mobility processing (ie.
the addition of an home address option, ...). It is easy to implement
and is enough if IKE computes its source address by a connect(peer)
followed by getsockname(), ie. the standard way to do it.
> 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 agree but I don't know if I am going to change my opinion about this
in a new future. At least it should be well documented (then my first
question).
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.
=> again in general I prefer freedom to overspecification. My concern is
I have not concrete example to see if this position is reasonnable or
will lead to major interoperability problems.
Thanks
[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]
--------------------------------------------------------------------
