[70346] in North American Network Operators' Group
Re: IPv6/IPv6 threat Comparison Paper available for review
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Tue May 11 05:32:23 2004
In-Reply-To: <20040511091916.894A939@coconut.itojun.org>
Cc: NANOG list <nanog@nanog.org>
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Tue, 11 May 2004 11:31:33 +0200
To: itojun@iijlab.net
Errors-To: owner-nanog-outgoing@merit.edu
On 11-mei-04, at 11:19, itojun@iijlab.net wrote:
>> - Smurf
>> I don't think you mention that in IPv6, there are no mechanisms that
>> allow an incoming unicast packet to be turned into a broadcast or
>> multicast packet, and as such, smurf-like attacks are impossible.
> There are cases where malicious IPv6 packet leads to IPv4 smurf
> attack (due to wacky IPv4 mapped address and API).
> i think it worthwhile to look at threats due to IPv4/v6 interaction.
You can obviously craft an IPv6 packet that will be delivered to an
IPv4 subnet broadcast address through 6to4 or some such, but unless the
hosts that receive the subsequent broadcast (that shouldn't be
generated unless v4 isn't properly administered in the first place so
it's still not an IPv6 issue) reply with something, nothing is going to
happen.
> draft-itojun-ipv6-transition-abuse-xx.txt
> draft-cmetz-v6ops-v4mapped-api-harmful-xx.txt
> draft-itojun-v6ops-v4mapped-harmful-xx.txt
Yeah, yeah, everything is harmful. I don't think having IPv4-specific
and IPv6-specific code in applications is the answer, though.
