(Top-posting because the whole message is context. Oh, and I'm lazy.) I do indeed love it when people break out IPv6 addressing as "there's so many addresses, we'll never ever go through them!" Sure, if they're only used as end-point identifiers. Say you want to crack out that 64k-port space into something bigger, because say p2p becomes so wide-spread and ingrained in our society, that 64k port space per IP becomes silly. So we say, break off another 16 bits and have a host just listen on not a /128, but on a /112. Cool, 4 billion "ports". That fixes the port space. Then someone comes along with a bright idea. "Hi!" she says, "Since hosts are already listening on a /112 of space (and thus all those pesky ND cache problems have been fixed!), we can start allocating cloud identifiers on peoples' hosts, so each cloud application instance gets a separate address prefix; thus any given host can run multiple cloud instances!" Let's call that a 32 bit address space, because I bet a 16 bit "cloud ID" doesn't scale. A 16 bit cloud identifier takes it down to a /96. A 32 bit cloud identifier takes it down to /80. Cool. Now you've got all these end-hosts all happily doing p2p between each other over a 16-bit extended port space, then running p2p and other apps inside a 32-bit cloud identifier so they can both run their own distributed apps/vms (eg diaspora), or donate/sell/whatever their clock cycles to others. What did that just do to your per-site /64? That you have no hope of ever seeing a user use up? It just turned that /64 into a /112 (16 bits of port space, 32 bits of cloud identifier space.) What's the next killer app that'll chew up more of your IPv6 space? I'm all for IPv6. And I'm all for avoiding conjecture and getting to the task at hand. But simply assuming that the IPv6 address space will forever remain that - only unique host identifiers - I think is disingenious at best. :-) Adrian On Tue, Jan 25, 2011, Owen DeLong wrote:
I love this term... "repetitively sweeping a targets /64".
Seriously? Repetitively sweeping a /64? Let's do the math...
2^64 = 18,446,744,073,709,551,616 IP addresses.
Let's assume that few networks would not be DOS'd by a 1,000 PPS storm coming in so that's a reasonable cap on our scan rate.
That means sweeping a /64 takes 18,446,744,073,709,551 sec. (rounded down).
There are 86,400 seconds per day.
18,446,744,073,709,551 / 86,400 = 213,503,982,334 days.
Rounding a year down to 365 days, that's 584,942,417 years to sweep the /64 once.
If we increase our scan rate to 1,000,000 packets per second, it still takes us 584,942 years to sweep a /64.
I don't know about you, but I do not expect to live long enough to sweep a /64, let alone do so repetitively.
Owen
-- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -