Ole,
I try to ping some routers on one of their
Subnet-Router anycast addresses (SRAA).
(http://tools.ietf.org/html/rfc4291#section-2.6.1)
Some (Cisco) reply with an unicast source address
(same subnet prefix).
Another one (Alcatel) reply with the SRAA as source
address.
A Linux
Ole,
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.
Are a
Brian
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
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
=?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= fx.leb...@yahoo.com 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,
--- On Mon, 10/3/11, Thomas Narten nar...@us.ibm.com wrote:
fx.leb...@yahoo.com 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
At IESG's recommendation and with the support of the authors of 3627 and 6164,
I put together a quick one-pager making 3627 historic. I think this one can
move through quickly, but since the other documents went through 6man, I
thought it made sense to ask for WG adoption of this document.
