On 2011-09-29 14:13, Mark Andrews wrote:
> In message <4e838725.9010...@gmail.com>, 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
There's a similar issue in RFC3068 (anycast 6to4), which is
described in RFC6343, so I will not give details here.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
