I have a slight problem with stating that "Vast IPv6 address space
actually enables IPv6 attacks".
So do I.
As noted, so do I. 
Compared to IPv4, scanning IPv6 is much, much harder, and that
is (I think) the most important thing to know.
IMO, the important thing to know is that IPv6 host scanning attacks are
not infeasible -- even when it has been used as a marketing argument for
years.
The analysis was good in that it offered a bit of consideration to the
scanning issue, but...
"Some estimates peg the length of time for a host-scanning attack on a
single IPv6 subnet at 500,000,000 years!"
It's not an estimate. It's a approximation based on scanning a /64
subnet at a thousand probes per second. 18 billion billion (addresses in
one /64) divided by one thousand, divided by 31536000 (the number of
seconds in a year) - works out to about 500,000,000.
Exactly. Nice math, but it suffers from an incorrect assumption: that
attacker will do brute force scans in the same way that they did for v4.
In v4, the scale of the "problem" was small enough that even doing a bad
job a la "brute force" was good enough. With v6, one needs to put more
brains into the scanning logic, or else won't be able to get away with it.
.Embed the MAC address;
.Employ low-byte addresses;
.Embed the IPv4 address;
.Use a "wordy" address;
.Use a privacy or temporary address;
.Rely on a transition or coexistence technology.
Why do you not mention DHCP in this list? You do mention it elsewhere.
DHCPv6 will in general supply random addresses. You say that "some"
DHCPv6 servers produce sequential addresses - could you please give an
example? I use Nominum's DCS, which certainly does NOT do this very
foolish thing.
Let me check what I'm running in my test lab (I will come back to you
regarding this one) -- most likely KAME's implementation?
Low-byte addresses are generally going to be on high-value devices,
which will usually be servers (whose existence is thus public knowledge
anyway)
There's a subtle detail here: One thing is having individual addresses
being publicly available, but another is being able to find them all
very easily.
Example: Say I'm running hundreds of web sites on the same subnet (just
an *example*).. You might argue that each of those addresses is 2public
knowledge". However, that doesn't mean it's trivial for an attacker to
(easily) find out all "alive" sites on a given subnet. If you use
predictable addresses, that becomes possible.
Embedded IPv4 addresses are going to be a reducing problem, and in the
scenario you mention, as well as in most other scenarios, again mostly
on machines that have very strong protections from firewalls and their
own packet filters.
I tend to disagree about "strong protection". For instance, recent
findings seem to indicate lack of parity in filtering rules for v6 and
v4 -- i.e., unfortunately, it's quite common that something that is
blocked in v4 is *allowed* on v6.
Wordy addresses will be an issue for some vanishingly small percentage
of systems, and generally systems that their owners want people to see
(Facebook being a good example). These are generally going to be systems
whose existence is public knowledge anyway.
Agreed.
All transition technologies are a reducing problem. The primary
transition technology - dual stack - has no technology-specific problems
in respect of scanning (except perhaps that the scanner, at least in
theory, gets two bites at the cherry).
Agreed.
I think you are making a minor issue look far bigger than it is.
IMO, IPv6 host scanning attacks being feasible is not e big thing by
itself -- for instance, we have "survived" this problem for v4, so at
least in theory there's no reason to believe that the sky is going to
fall for the v6 case.
What *is* important, IMO, is the amount of IPv6 mythology that there is
out there, which leads to incorrect assumptions, and eventually to
negative implications.
From the general "security considered during the design of the protocol
rather than as an 'add on'" to "scanning attacks are impossible".
When it comes to scanning, IMO it's more of "oh, yeah, it's feasible..
and the fix is obvious... let's fix it", than "let's gets scared about
ipv6 host scannign".
I feel
the privacy issues around SLAAC are far more significant in the real
world than any threat from scanning.
Unfortunately, one still hears in IETF corridors things like "not
everyone needs privacy" from some mobile vendors... (sigh)
PS: I still like your RFC about stable privacy addresses.
Thanks. That's where the "meat" is.. FWIW, articles such as the one I
forwarded are mostly meant to raise awareness, such that folks in the
position of implementing stuff such as
draft-ietf-6man-stable-privacy-addresses actually do it.
PPS: There seems to be a diagram missing in the discussion of embedded
MAC addresses, after the word "syntax".
Will check.
Thanks!
Cheers,