The mobility model that Joe and I discussed requires a security association to be set up with the anycast address (IPSEC management protocols reply with the anycast address as a source), supply a COA, and then TCP is set up to the COA.
But we still have to get a message from the anycast server that somehow says "I am a valid responder to that anycast address, but use this other address instead during this session."
On Apr 6, 2005, at 1:09 PM, Manfredi, Albert E wrote:
From: Joe Abley [mailto:[EMAIL PROTECTED]
Correct. However, the v6 addressing spec prohibits the use of an anycast address from being used as the source address in a datagram, or being bound to an interface on a host. These two restrictions effectively prohibit the use of anycast as a service distribution mechanism.
Any reason why the same rules that apply to multicast addresses wouldn't also work here?
The destination address is anycast, to find the service. But the source address in the reply is the unicast address of the first server to respond, which presumably is the closest one at the time.
This may circumvent the authentication issues, by making any subsequent TCP session start as a regular unicast?
Bert
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
