Usenix: Google deploys IPv6 for internal network

Though the project is only halfway finished, Google's IPv6 network is already bearing fruit

By , IDG News Service |  Networking

Google's internal network spans more than 200 offices worldwide, serving about 30,000 employees. It consists of a wide variety of devices from companies such as Cisco Systems, Juniper Networks, and Aruba Networks, hundreds of commercial and home-built applications, and a range of operating systems, including Linux, Mac OS X, and Microsoft Windows.

The engineers modeled the IPv6 network as closely as possible on the existing IPv4 one, to keep the routing and traffic flow largely the same. At first they ran IPv6 over the IPv4 networks, a process called tunneling. Then, in cases where it was feasible, they set up dual stacks, where IPv4 and IPv6 run side by side. Eventually, they want to make the network IPv6 only.

To assign IPv6 numbers to devices, Google followed the guidelines in the Internet Engineering Task Force's RFC 5375. Each campus or office got a /48 address block, which meant that it was allotted 2 to the 80th power addresses. In turn, each building got a /56 block of those addresses (or about 2 to the 72nd power addresses) and each VLAN (Virtual Local Area Network) received a /64 block, or about 2 to the 64th power addresses. To assign numbers to specific devices, the engineers used the Stateless Address Auto-Configuration capability (SLAAC), which allows the devices to assign numbers to themselves. This approach eliminated the need to manually assign numbers to each device. It was also necessary in that at least some operating systems do not yet support DHCPv6, the version of Dynamic Host Configuration Protocol server-based addressing mechanism for IPv6 networks.

One of the major issues was inadequate support for IPv6 in network devices and software, Nikolova said.

Many network devices now only support IPv6 in software, meaning that much of the traffic processing is carried out in software, rather than with customized hardware. As a result, IPv6 network operations consume more processor cycles than IPv4 operations do. At least one wireless equipment vendor did not support ACLs (access control lists). Also, the network's WAN (wide area network) acceleration devices can not encrypt IPv6 traffic, because the protocol they use--WCCP (Web Cache Control Protocol)--does not yet work with IPv6. In addition to networking gear, printers remain problematic, in that many do not fully support IPv6.

Application and OS compatibility also proved to be a challenge. The company has been phasing out those applications that do not support IPv6, though many essential tools, such as databases and billing applications, remain in operation because they can not be modified or upgraded easily. And while the current versions of most OSes support IPv6, they do not do so by default, which causes additional work on the part of administrators and users.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

NetworkingWhite Papers & Webcasts

See more White Papers | Webcasts

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness