Suresh Krishnan said: > On Wed, 10 Mar 2004, Jeroen Massar wrote: >>I guess that Jyrki's thoughts where more along the lines of: >>"What if I send a simple ICMPv6 Echo Request with *your* source address". > > Aha. That makes more sense to me. But why should we point to just ICMPv6 > Echo request? Pretty much all data packets which need an ack can be used > for this attack. It could be any protocol, not just ICMPv6. Anyway all the > more reason for a MUST NOT.
Wait a minute... Now we're talking about prohibiting ANY multicast app from responding unicast to multicasted data? That's a basic part of functionality that is assumed in many apps! Can someone explain why we're looking for a different solution to this behavior for IPv6 when the IPv4 behavior is already set in stone? For apps which may not even be aware which version they're using, why should IPv6 not respond in some or all cases when IPv4 always does? >>The only real solution for this of course is filtering, but I am >>not going to see that happen knowing that quite a number, make >>that most, IPv4 based ISP's don't filter their customers on source >>addresses. Even RFC1918 addresses seem to be unfiltered at most ISP's. >>Talking about source filtering here, which should be very easy as >>you know yourself as an ISP which prefixes one assigned to that user >>or simply to yourself as an ISP, a simple "source !myprefix drop" >>entry in your peering/transit router fixes this all, better stick >>as close to the client as possible et voila. I don't see the relevance of this to multicast, since RPF inherently stops all off-subnet spoofing. What problem are we trying to solve? S -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
