Google Deploys IPv6 For Internal Network

itwbennett writes "Google is four years into a project to roll out IPv6 to its entire internal employee network. At the Usenix Large Installation System Administration (LISA) conference in Boston last week, Google network engineer Irena Nikolova shared some lessons others can learn from Google's experience. For example: It requires a lot of work with vendors to get them to fix buggy and still-unfinished code. 'We should not expect something to work just because it is declared supported,' the paper accompanying the presentation concluded."

Comments

Supported

[inglorion_on_the_net]

"'We should not expect something to work just because it is declared supported,' the paper accompanying the presentation concluded."

I think that if something is declared "supported", it is perfectly reasonable to expect it to work. If it turns out it doesn't work, I think the problem is more that the vendor hasn't done as good a job as they should have than that your expectations were too high.

Re:Supported

[Chuckstar]

I don't think they meant "we shouldn't hold the vendors accountable if the equipment doesn't work right".

I think they meant "we shouldn't expect that just because the vendor says it works, that it does".

Google has the benefit of size. If Google calls up Cisco and say "please fix this problem that exists in the thousands of routers we buy from you", it'll get fixed. If you or I call up Linksys and say "please fix this problem that exists in this one router I bought from you"... well... don't hold your breath.

Re:Supported

[jimicus]

I think that if something is declared "supported", it is perfectly reasonable to expect it to work. If it turns out it doesn't work, I think the problem is more that the vendor hasn't done as good a job as they should have than that your expectations were too high.

Indeed, but it's the same with all commodity technology - you find various implementations, not all of which work properly.

The same was true 10 or 15 years ago with booting from CD. Same was true 5-6 years ago with PXE. Same's true with CIDR - I've come across equipment like printers that can't handle the idea - you have to give them a class A, B or C subnet mask. Same with STP (spanning tree) - I've met switches that just plain don't work if you turn on STP then plug in a cheapie unmanaged switch - and I don't mean the port plugged into the cheapie switch doesn't work, I mean the entire expensive managed switch doesn't work. Only a couple of weeks ago I met a server BIOS providing software RAID (yeuch) that needed the drives set to RAID in the BIOS for it to work. But if power to the server was lost, that specific BIOS setting would go. Every other BIOS setting would be just fine and you'd get no error at bootup; you'd just find your disks magically appeared differently on boot.

If Google's network team honestly thought that any product with "IPv6 supported" on the label meant "Every aspect of IPv6 fully supported, tested, interoperable with other vendor's implementation - basically it'll work as well as you'd expect IPv4 to work in something released in the last five years", they're displaying incredible naiveté.

Re:IPv6

[Anonymous Coward]

assignment of smaller blocks may have extended the life of IPv4 addresses however, there are physically not enough addresses for the devices we currently have. While, there may be enough at the moment, there wont be soon.

What is IPv4; 4.3 billion addresses. There are over 6 billion people on earth and many people in the western world have numerous devices. My household of 2 has 8 devices that are nearly always online. (Computers, Phones, Top-set Boxes, printers, etc....) This number does not take into account either one of our work sites which probably add another 1-2 addresses to that number.

And no, NAT is not a solution.

Re:IPv6

[Mr. Underbridge]

Right, if decades ago the inventors of the internet had realized that it would scale from 10s of users to billions. I'd say the address space length that they used still makes it outrageously overengineered for the time, and we're lucky they had the vision that they did. To criticize them is preposterous.

Re:The fine article is wrong

[KiloByte]

Uhm, it's obvious something dropped <sup> tags. Just like, for example, Slashdot does.

Try this: 2⁸⁰ -> 280. Not the writer's fault, the blame lies on editors who didn't notice their software mutilates basic harmless tags.

It took Google 4 years...

[s7uar7]

Just think how long it would take companies without access to virtually unlimited funds and brain power. It's no wonder everyone is reluctant to make the move.

Re:Vendors

[Lennie]

Because the hardware that can handle large amounts of small packets fast when you install your own software ('firmware'), does not exist AFAIK. Atleast not the type which will also be supported by (multiple) vendors (no1 wants to be stuck on, locked into, one vendor). designing not-massproduced ASICS isn't cheap. It would be like Google designing their own CPU's for their servers.

The closest things are:

- NetFPGA (some people at Google worked on that project I believe) / LibreRouter - which use FPGA's to handle packets, you tell it how to do that.

- projects like Netmap, handle packets in userspace so you don't have to push packets through the kernel on normal PC-hardware, making it faster: http://www.youtube.com/watch?v=SPtoXNW9yEQ

The best chance currently to be useful in 'doing your own thing' is probalby:

- OpenFlow, which basically is an API standard which multiple vendors would support to describe what the hardware in a switch should be doing, a programming language almost. Some demo's:
http://www.youtube.com/user/stanfordopenflow

Which can allow for lots of tricks, like 'software defined networking'

Re:IPv6

[allo]

you see, the good thing is not the NAT, but the firewall dropping packets from outside, again. As always, the people say the security comes from NAT, and really mean the requirement of having a firewall which drops packets coming in, because there is no mapping to which internal ip they should be routed.

Re:IPv6

[tyler_larson]

Decades ago, the engineers did in fact consider 128 bit addresses, but in the end they went with 32 specifically because v4 was not considered a "production" version. There's a link on the wikipedia page for ipv6 to a video with vint cerf explaining exactly that.

Re:IPv6

[Pi1grim]

NAT killed one of the basic principles of the internet and you're trying to make it look like a good thing.