At 10:10 AM +0900 6/4/01, Jun-ichiro itojun Hagino wrote:
> the condition "don't put anycast into source" was introduced because
> of tcp issues, as you've described.
Itojun,
TCP is not the only reason for the restriction against using an anycast
address as a source address. I can think of at least two other reasons,
and there may well be more:
(1) This restriction avoids the hazard of an ICMP error message
being sent, regarding an erroneous packet, to a node that
did not originate that packet.
(2) For a packet whose destination is a multicast address, this
restriction ensures that those multicast routing algorithms
that use reverse-path forwarding will continue to work correctly.
Basically, there are a number of places in the current architecture
that assume that the source address of an IP packet identifies a single
node; the restriction against using an anycast address as a source
address ensures that we don't break anything that makes that assumption.
The resulting requirement -- that request-response-style applications
not simply swap the two addresses when sending a response message --
is needed anyway for responding to multicast requests, and has been
satisfied long ago in most implementations of common UDP-based or
ICMP based applications (such as ping), so ought not to be that hard
to comply with.
Steve
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
