Subject: Comments on draft-ietf-ipngwg-icmp-v3-02.txt

From: "Dave Thaler" <[email-masked]>
Date: Wed, 24 Jul 2002 15:06:40 -0700

I had a comment on the ICMPv6 spec which I mentioned to Steve Deering in
Yokohama
and promised I'd also send to the list:

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).
One example of this is if a node receives a TCP SYN on an anycast
address, today it
apparently has to silently drop the SYN, and the other end can't tell
why.
No existing ICMPv6 error message applies to this case.

(Also I had mentioned that the RFC does not say what to do when
receiving an anycast 
Echo Request, but draft -02 already does so no problem there.)

-Dave

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 25 Jul 2002 07:12:24 +0900

>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).  One example
>of this is if a node receives a TCP SYN on an anycast address,
>today it apparently has to silently drop the SYN, and the other
>end can't tell why.

	draft-itojun-ipv6-tcp-to-anycast-01.txt proposes to use addr unreach
	(code = 3), but i'm happy to see a new code for anycat case.

itojun

---

From: Randy Bush <[email-masked]>
Date: Wed, 24 Jul 2002 15:16:51 -0700

> 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).  One example of this is if a node receives a
> TCP SYN on an anycast address, today it apparently has to silently drop
> the SYN, and the other end can't tell why.  No existing ICMPv6 error
> message applies to this case.

there is an easier fix for this.  un-break sourcing anycast packets from
their proper address.

randy

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Jul 2002 08:57:41 +0300 (EEST)

> there is an easier fix for this.  un-break sourcing anycast packets from

Exactly, plus e.g. "addr unreach" is good enough if you can't.

(Note: a node should never have an anycast address of scope X if it does
not also have a unicast address of at least scope X.)

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Rami Lehtonen" <[email-masked]>
Date: Thu, 25 Jul 2002 09:29:47 +0300

> No existing ICMPv6 error message applies to this case.

Not directly related to this issue, but...

There was also some discussion at MAGMA working group that if the edge
router starts to filter MLD Reports coming from a host (host authorization),
it would be nice to notify the host that such filtering is applied, e.g.
with ICMPv6 Administratively Prohibited. MLD Reports are however sent to
multicast address and thus the router can't use ICMPv6 (spec says that error
message MUST NOT be sent as a result of receiving a packet destined to an
IPv6 multicast address). So, what about one more exception to the ICMPv6
spec in addition to the Packet Too Big and Parameter Problem messages?

Rami Lehtonen

---

From: Thomas Narten <[email-masked]>
Date: Fri, 26 Jul 2002 14:33:11 -0400

> 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? 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). In general,
it might be hard to come up with clear rules for when to send such a
message and when not.

I believe most ICMP messages are generated in response to very
specific situations, where there isn't much thinking involved in
whether to send or not. Can we define what those situations are in the
case of your proposed message?

> address, today it apparently has to silently drop the SYN, and the
> other end can't tell why.  No existing ICMPv6 error message applies
> to this case.

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. 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.)

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.

Thomas

---

From: [email-masked]
Date: Mon, 29 Jul 2002 12:04:44 +0900

>Exactly, plus e.g. "addr unreach" is good enough if you can't.

	pitfall alert:

	the term "anycast" is used with very vague definition here.
	Dave is talking about RFC2460 anycast, Randy is talking about "unicast
	address appear in multicast location" anycast (pseudo-anycast in
	draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt).

	read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this
	topic.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Jul 2002 07:14:10 +0300 (EEST)

> 	read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this

Please elaborate.  I don't think the draft discusses this at all.

With RFC2460 anycast, you can always assume there is another unicast 
address of at least same scope assigned on the node.  As the node cannot 
use RFC2460 address as a source address, it will use unicast address.  
Problem solved(?).

---

From: Robert Elz <[email-masked]>
Date: Mon, 29 Jul 2002 14:20:11 +0700

Date:        Fri, 26 Jul 2002 14:33:11 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | > 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

---

From: [email-masked]
Date: Mon, 29 Jul 2002 16:37:36 +0900

>Please elaborate.  I don't think the draft discusses this at all.

	Randy is talking about changing definition of "anycast" in RFC2460
	to definition in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt section
	2.2.  is it clear enough?

>use RFC2460 address as a source address, it will use unicast address.  

	i don't quite parse it.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Jul 2002 07:28:21 +0300 (EEST)

> 	to definition in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt section

No, he isn't.

There seem to be some unstated assumptions here.

What he is saying is 'if you try to connect anycast address PRFX::/64, the 
ICMP unreachable (or whatever) message comes back from PRFX::X/64 (unicast 
address on the node)'.

This applies to RFC2460 anycast only, and depending on source address 
selection, possibly pseudo-anycast.

> >use RFC2460 address as a source address, it will use unicast address.  

See above.  There should be no nodes which have only RFC2460 anycast
address(es), as they must not use it as a source address.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Jul 2002 16:51:51 +0300 (EEST)

On Mon, 29 Jul 2002, Randy Bush wrote:
> i think he is.  but i could be wrong.  after all, he has said it about
> 42 times not.
> 
> i don't think he was saying that.  but again, i could be wrong.

Ok, I misunderstood your statement.

Above was my similar but different opinion why ICMP packets triggered by 
traffic to an anycast address should not be a problem.

---

From: Randy Bush <[email-masked]>
Date: Mon, 29 Jul 2002 22:34:18 -0700

> address(es), as they must not use it as a source address.

brokenness

randy