Date: Fri, 26 Jul 2002 14:33:11 -0400
From: Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| > I'd like to see an ICMPv6 error message value assigned for the case
| > where a node would need to send a packet from a specific address,
| > but cannot because that address is anycast (since the other end has
| > no other good way of knowing this is the case).
|
| Under what conditions would such a message be sent?
I'd suggest "any time a packet is received at an address which is
correct for the node, but inappropriate to use for the particular
packet received".
That includes TCP SYN sent to an anycast address (and Randy, I don't
believe that any redefinition of how anycast addresses are permitted
to be used can ever make TCP to an anycast address reliable).
But it might also be useful for other similar functions - perhaps use of
an address of a scope that the destination node doesn't want to use (like
you sent that SMTP request to my link local address, but I really don't
want you to do that).
The ICMP message should contain a better address to use, which the source
could compare with its list of possible addresses for the destination, and
use only if that was one of the addresses it was considering using in the
first place (that avoids most spoofing attacks I think).
| For many uses,
| sending to an anycast address should not trigger an ICMP (the higher
| layer in some cases *could* deal with an anycast address).
Of course, this would be done only if the anycast addr couldn't be
handled.
| The above isn't immediately obvious to me. TCP *could* also use the
| recieved SYN as an indication that it should send a SYN in the reverse
| direction using a proper source address.
I don't think that would be a very useful technique. All that's going to
do is attempt to open a new connection to something that won't be in LISTEN
state (it isn't a case of simultaneous open, as the addresses don't match).
That will just elicit a RST.
| That SYN might even include a
| option connecting it to the anycast address to which the first SYN was
| directed. (Clearly details would need to be fleshed out to make this
| all work.)
Something like that could be done, but this is going to take much work
on TCP, which isn't even in the pipeline. Even then, it isn't clear that
this would always be appropriate, so there still needs to be a way to
indicate that the address used (while valid) isn't the correct one to use.
(A new ICMP like this could also be used in place of some current uses of
port unreachable).
| My point here is it's not immediately obvious to me when an
| implementation is supposed to send an ICMP message in response to a
| packet sent to an anycast address.
If an implementation can't work out when to send it, then it won't. I don't
see this as a problem. It would be a bigger problem if it wasn't clear what
should happen when such a message is received - that might make it useless.
But if any nodes can find a way to decide when to send the message, that's
enough from that end - and nodes that want to simply prohibit all TCP sent
to anycast addresses would be in that set I'd expect.
I support Itojun's request.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
