I P in the Pool.

Internet Protocols and address pools, that is!  IP, the Internet protocol, is one of the foundational support structures of  the Internet that supports our gaming. IPv4, the first widely adopted version, was specified in RFC 791 during September 1981. IPv4 is a connectionless protocol for use on packet-switched networks such as Ethernet. It is a 'best effort' delivery protocol, that is, there is no guarantee of packet delivery, nor assurance of  proper sequencing of packets, nor any guards against packet duplication. These aspects, usually important for useful network communication, are handled by higher-level protocols on top of IP, such as TCP. UDP traffic, the most common for online games, is also a protocol that rides over IP.

At the core of the IP protocol is the concept of addresses. You've probably seen these on you gaming machine with references to things like 192.168.1.2, etc. The IP address consists of four Octets (less pedantically known as Bytes). So the same example address can be written as 0xC0.0xA8.0x01.0x02 in hexadecimal notation or 11000000.10101000.00000001.00000010 in binary (usually done when manually calculating subnet information).

The IP address, since it consists of four octets, has a total of 2^32 available addresses. There are actually fewer available for actual use, since parts of the specification allow for specialized addresses for use by things like broadcast traffic, loopback, testing, etc. Even so, there are a bit over 4,000,000,000 unique addresses available for use.

Early on, the bodies (most notably the Internet Engineering Task Force, IETF) involved in the design and specification of Internet protocols and technologies realised that an address pool of this size would likely become insufficient at a future time, and designed mechanisms to effectively extend the size of the available address pool. The almost universally used mechanism is known as Network Address Translation, or NAT. NAT allows Local Area Networks (LAN) to reside on some segment of addresses defined in the protocol as private while providing bidirectional access to public WAN addresses. Your PC, using a 192.168.#.# address, is on one such private address. Among other characteristics of Private addresses is that they are non-routable, that is, once they reach any router, they are kept on the LAN - no information is leaked to the WAN side of the router, and packets with addresses confined to the LAN will not be routed via the WAN. This ensures such packets from private networks stay on the private network.

So how does a PC on a LAN with a private address gain access to the rest of the Internet WAN residing at public addresses if their own traffic must remain on their LAN? That is of course the primary function of the router via NAT. Any traffic from a LAN PC destined for a public WAN destination has the address information in the packet manipulated by the router to appear to have originated at the public address of the WAN side of the router. Any return traffic is directed toward the public WAN address of the router, whereby the router manipulates the address information of the packet and forwards it to the appropriate PC on the LAN. For an excellent overview, see Network Address Translation in an unusually well written Wikipedia entry.

Using NAT, we can have tens of thousands of PCs on a LAN residing on one single public WAN address. Other groups of PCs can be residing behind other routers with other public WAN addresses, where the PCs on different routers may have the same private addresses, but there will be no conflicts: the WAN outside of each router cannot even 'see' the LAN since it is composed of private addresses, so no source of conflict can exist.

Even with this 'multiplication factor' of addresses provided by NAT, there is a growing shortage of available addresses: there is a growing number of services that need public addresses, and an explosion of devices (phones, media devices, even refrigerators!) that use addresses. Technologists in the field predict we will run out of IPv4 addresses sometime in 2011-2012.

The IETF realized early on a better solution would be needed, and started work in earnest in 1991. By 1998, RFC 2460 resulted, defining IPv6. The biggest change in this new version of IP is an address space consisting of 16  octets, or 128 bits. This means, compared to the roughly four billion (4,000,000,000) addresses available in IPv4, IPv6 has over 340 Undeciliion. That's a huge number, written out in its full glory,  it's:

340,000,000,000,000,000,000,000,000,000,000,000,000.

That's roughly seven IP addresses for each atom in each body of every human on the planet today.

Or about 3,120,000,000,000,000,000,000,000,000 (~3 Octillion) addresses for each man, woman and child that has ever lived on our planet (thanks, Population Reference Bureau). I think this will suffice for some time!

How long? To put this enormous number into perspective consider this: The age of the Earth is about 4.54 billion years. If we had been assigning IPv6 addresses for this entire period at the rate of 1,000,000,000 (one billion) addresses per second, we would have used a little over .00000000004% of the available address pool! It's BIG!

How big? If you imagine all of the IPv4 addresses mapped into the area of a space the size of one typical pixel of the display you're reading this on, the IPv6 address space would need a square about 52,500,000 miles on each side (thanks, WolframAlpha), roughly the surface area of 14,000,000 Earths.

An address space that large ensures every device on our planet can have a unique address, and completely eliminates any need for troublesome mechanisms like NAT (though there are proposals to retain such functionality for specific purposes).

IPv6 offers many other improvements compared to IPv4, such as much simplified address configuration options, much improved and intrinsic multicast support, mandatory network security support (IPSec), vastly simplified and improved handling by routers (no fragmentation by routers is allowed, PMTUD is mandatory), no header checksum is utilized (reducing processing load on routers), TTL replaced with Hop Limit (routers no longer need to make time in queue calculations), and vastly improved mobility components (no proxy/triangular routing, devices and whole subnets can move between  router points without renumbering), jumbogram support (packets up to 4,294,967,295 bytes long), and vastly improved extensibility (options are implemented as extension headers, effectively meaning unlimited protocol extensibility without requiring any changes in the basic protocol design).

Being the protocol newborn, adoption rates are in the early adopter stages: only a fraction of a percent of current Internet traffic at the time of writing is IPv6. Nonetheless, technologies to ease the transition  to IPv6 such as Teredo which tunnels IPv6 over IPv4 NAT using UDP, point-to-point tunnel services, etc. ensure that the migration to IPv6 will happen. It is not question of if IPv6 will be the predominant standard, but when. Behemoths such as Google are leading the charge, offering IPv6 interfaces to their search engine at ipv6.google.com and support for Google Services over IPv6 to compatible networks.

So why should we as gamers care about this? NAT is one of the primary culprits in connectivity issues for on-line gamers. Often, problems with the behavior or configuration of NAT in consumer routers result in spotty connectivity and sporadic connection problems. Additionally users that play peer-to-peer games or need to run a game server suffer all the slings and arrows of router configuration and port forwarding in attempts to attain proper game functionality.

IPv6 will eliminate the need for these machinations, providing a much more reliable, higher performance, more flexible infrastructure for on-line gaming.