Hi, On 2011/10/03, at 23:08, François-Xavier Le Bail wrote:
> --- On Mon, 10/3/11, Thomas Narten <[email protected]> wrote: >> <[email protected]> writes: >> >>> If the source address of reply differs from destination address of >>> the request, some applications are broken. >> >> If you are saying that applications should ignore the src >> address (in case it is anycast) when accpting replies, I very >> strongly disagree. > > I don't say that. > >> The norm is (and has been forever) to require that the >> source address in a response (whether TCP or UDP) match the destination >> address in the original query. And for good reason. > > But the RFC 3484, as I understand it, exclude anycast address from the > source replies. > > Section 4 of RFC 3484 states: > (http://tools.ietf.org/html/rfc3484#section-4) > 4. Candidate Source Addresses > [. . .] > In any case, anycast addresses, multicast addresses, and the > unspecified address MUST NOT be included in a candidate set. > > It might be useful to reassess this restriction, at least for the replies. As in RFC 3484 section 2, these algorithms in RFC 3484 does not specify the rules for your case. It specifies the rules that are used when an application initiates a session and a destination address and a source address have to be chosen. It does not specify rules for selecting address for a returning packet. So, in my understanding, the only restriction for using an anycast source address was in RFC 3513. But, now that such a restriction was removed, RFC 3484 should also be updated to allow to select an anycast source address for a initiating session. -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: [email protected] TEL +81-422-59-3334 FAX +81-422-59-6364 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
