Puzzeling about IPv6

Karl Auer kauer at biplane.com.au
Sun Nov 20 00:18:09 UTC 2011


On Sun, 2011-11-20 at 03:47 +0900, 夜神 岩男 wrote:
> > Oh, and given you've got 64bits to play with, so long as your random
> > numbers are up to scratch no need to worry about collisions.  You'ld
> > need to be assigning millions of addresses before you ran into that
> > problem.
> 
> Not to be an ass and this is likely a decade too early, but... this is
> direct echoes of what I heard 20 years ago.
> 
> Does systematic thinking belong in /32+ IPv6 addressing or is it in
> fact safe to just random it all away willy-nilly?

Rather look at the address space size, you need to be looking at the
subnet size.

Choosing random addresses in the (typically) /24 space of a single IPv4
subnet won't work because 256 addresses is so few that the likelihood of
collision is too great. With random addresses chosen in the very common
smaller IPv4 subnets like /25, /26, /27, collisions are even more
likely.

Choosing random addresses from the /64 space of a IPv6 subnet, on the
other hand, *is* a valid approach, because the address space in such a
subnet is so very large. Choosing random addresses in such a subnet will
work for a very large number of hosts. Such a large number of hosts, in
fact, that physical limitations will most likely be in force before the
logical limitation of address collisions becomes relevant.

It may be true that we hit the physical limitations earlier than we
expect, but it won't change the mathematical properties surrounding the
selection of random addresses in such large spaces.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20111120/f8e1ebd7/attachment.bin>


More information about the bind-users mailing list