Mark, > Brian E Carpenter writes: > > On 2011-09-28 21:42, François-Xavier Le Bail wrote: > > > > > > So, if the RFC 3484, Section 4 "Candidate Source > > > Addresses" is involved in the reply to datagrams sent > > > to an anycast address, it might be useful to reassess the > > > restrictions that excluded an anycast address from the > > > "candidate set", at least for the replies. > > > > You would need to start a thread proposing a specific change to > > draft-ietf-6man-rfc3484-revise if you want this to be done. > > > > I'm not convinced; as Ole said, anycast remains a special case > > for certain applications, so it will be hard to define > > a safe general rule. > > Brian > > Just for reference, in the last week, there was a compliant > in bind-users that we were rejecting replies to queries sent > to the all routers IPv6 anycast address because the source address > of the reply did not match the destination address of the > query. The anycast address can be used as source address relatively > safely, even for TCP, if you constrain the packets to be fragmented > at network MTU and to also include a fragment header in case > they are going through a IPv4/IPv6 translator. With anycast > you don't want to trigger PMTU discovery. > > Mark
Thanks, another argument for a reply with an anycast address is given in RFC 4942: 2.1.6. Anycast Traffic Identification and Security [. . .] To avoid exposing knowledge about the internal structure of the network, it is recommended that anycast servers now take advantage of the ability to return responses with the anycast address as the source address if possible. François-Xavier -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
