[CentOS] IPV4 is nearly depleted, are you ready for IPV6?

Tue Dec 7 20:13:38 UTC 2010
Ben McGinnes <ben at adversary.org>

On 8/12/10 4:12 AM, David Sommerseth wrote:
> On 07/12/10 16:49, Bob McConnell wrote:
>>
>> No, it is not FUD, it is a real concern by people with much to lose. 
>> Those of you evangelizing this new, and still unproven technology can't 
>> seem to recognize this simple fact.
> 
> This is FUD. 

Agreed, but I'm not adding more to the pro-IPv6 chorus, because it's
already being covered very well, both here and on NANOG (and
ipv6-ops).

> And due to the enormous address space IPv6 gives each single site,
> doing a brute-force attack against more IP addresses will be a
> never-ending story.  Try to double 4.294.967.296 32 times, and
> you'll have the number of addresses available *only to you* in *one*
> /64 subnet.

Anyone wanting a nice clear explanation of the numbers of IPv6 address
space:

http://www.ripe.net/info/info-services/addressing.html

> If you then even introduce IPv6 Privacy Extensions, which will
> randomise and change the IPv6 address regularly, an attacker will
> shoot at a moving target.  Then put this "moving target" behind a
> firewall which doesn't provide access from the outside to the inside
> (only from inside to outside), and the attacker will not know if he
> hits or not.

This coupled with statefull firewalling should cover everyone's needs.

No doubt there will still be people like Bob who will remain
unconvinced until everyone around them become the proof.  If they
really want to deliberately break things to retain their NAT-like
world, they can configure a single box with 6to4 and 4to6, give it a
/128 and then run their existing v4 NAT space behind that.  They'll
get very little sympathy when it breaks other things, though.


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20101208/eb6ccdb0/attachment-0005.sig>