Google Engineers Say IPv6 Is Easy, Not Expensive

alphadogg writes "Google engineers say it was not expensive and required only a small team of developers to enable all of the company's applications to support IPv6, a long-anticipated upgrade to the Internet's main communications protocol. 'We can provide all Google services over IPv6,' said Google network engineer Lorenzo Colitti during a panel discussion held in San Francisco Tuesday at a meeting of the Internet Engineering Task Force (IETF). Colitti said a 'small, core team' spent 18 months enabling IPv6, from the initial network architecture and software engineering work, through a pilot phase, until Google over IPv6 was made publicly available. Google engineers worked on the IPv6 effort as a 20% project — meaning it was in addition to their regular work — from July 2007 until January 2009."

Comments

Comment removed

[account_deleted]

Comment removed based on user account deletion

easy?

[Scrameustache]

I wouldn't call something that take 18 months to do "easy".
Maybe that's why I don't work at google :-|

Re:easy?

[Aladrin]

In a company of 10,000+ employees, it took a 'small team' only 18 months to convert and test what took 11 years to build? I think that's pretty good.

Re:easy?

[holophrastic]

It may be "pretty good", hey it may be great. But if they're saying that it's easy enough for anyone to do, that's jsut not the case. At 20% of 18 months, that's almost 4 months of solid labour. If you told me that my business needed to take 4 months to do something, I'd tell you it had better be revenue-generating.

Re:easy?

[Bert64]

How big is Google's network compared to most companies?
And also consider the people doing this weren't working on it full time and were a relatively small team.

The hardest part of deploying IPv6 is actually getting IPv6 network transit... Very few ISPs will offer it, or charge a high premium for it ontop of their ipv4 charges such that it isn't worth the expense.

Re:easy?

[at_slashdot]

Everything is easy for a team of PhDs that has free time on their hands.

Re:easy?

[VPeric]

On the other hand, it's 4 months for the whole of Google. And Google is huge. So it's a fair assumption that it'd be much less than 12 months for something a fraction of Google's size.

Re:easy?

[Anonymous Coward]

At 20% of 18 months is for google with its tens of thousands of computers.

I have IPv6 at my home and I got it set up in maybe 3 hours at the most, and that is with one person, 15 computers, 2 routers, and setting up a DNS server.

Re:easy?

[D Ninja]

If you told me that my business needed to take 4 months to do something, I'd tell you it had better be revenue-generating.

If you're Google, and you're thinking long term (something severely lacking with many people), it is revenue generating...especially if they're in the forefront of providing support for the technology.

Re:easy?

[Ephemeriis]

If you told me that my business needed to take 4 months to do something, I'd tell you it had better be revenue-generating.

That's the big problem with the IPv6 transition.

Regardless of how easy or necessary it may (or may not) be, it isn't going to generate a whole lot of revenue right now. Maybe for a web-based company like Google it might actually get them some revenue... But for your average business that just uses their network to email, browse the web, transfer some files, etc... It'll take some money and some labor, but won't really get you anything in return.

It's hard to pitch something like that to management.

Re:easy?

[Anonymous Coward]

And ipv6.google.com still poorly work from an ipv6-only host...

They must be joking.

Re:easy?

[sexconker]

Google is NOT huge, and it is very young.

To get a real corporation on IPv6 will takes years of constant work, and even then you'll still have legacy systems hooked up to analog lines doing whatever it is they do on their data/fax modems.

The reality is there are TONS of legacy systems out there that can NOT be replaced with any currently available "solutions".

Re:easy?

[fuzzyfuzzyfungus]

On the other hand, Google really rocks the homogeneity, so I would suspect that length of task doesn't scale with size all that evenly.

If you have 100,000 computers doing some task, you already have means in place to update them cleanly and easily(or you are doomed). Making and testing the changes will account for 90+% of the time, just pressing "deploy" at the end will be (comparatively) trivial. An outfit with 100 computers still has to do the first 90%

Re:easy?

[Sancho]

It should also take a lot less time and fewer resources for companies smaller than Google--or at least, with a smaller web presence.

That's the rub, though. Companies with a large web presence have more incentive to enable IPV6. Companies that aren't technologically-oriented will be easier to migrate, but will be less likely to do so soon. It parallels the emergence of the web, to some degree.

Re:easy?

[TheRaven64]

Spoken like someone without a PhD. What you say is true only where the value of 'everything' is defined as 'procrastination'.

Re:easy?

[Anonymous Coward]

It took 11 years to build all of Google. How many of Google's apps really give a rat's a$s about whether the network they're riding on is IPv6 or IPv4? If their code is at all modularized, it's probably less than 0.01% of their entire code base. In this light, 18months is a lot less astounding.

Re:easy?

[Anonymous Coward]

Am too Google, you insensitive clod!

Re:easy?

[Anonymous Coward]

cool, it take me 10s to boot this computer which took 25years to achieve the current state.
oh wait, more like 50years
It even has ipv4 and ipv6 builtin! 10s !

fucking irrelevant comments like ours being modded up make me feel humanity is still going into the wrong direction

Re:easy?

[holophrastic]

I have fewer personnel, and many more "products" than google. Oh, and a much less forgiving set of clients. For me to upgrade such things, I have to go and test all of my products -- everything I've built for the last 15 years. And then handle every one of my 100 clients -- and upgrade them. Google has it easy. All of their stuff is in one place. They also have the scale and redundancy to upgrade things without taking them down. I don't. Oh, and my clients have their own hardware that is compatible to the old spec. You expect me to tell them to buy new hardware?

Re:easy?

[tukia]

That's if you're assuming that they're not spending most of the time waiting for approvals from various departments to touch their network products and also to schedule any equipment upgrades. I was involved once in an IPv6 pilot project for a certain government and most of the time spent was just waiting for permissions to touch various equipments. The actual task could probably be done in a day (or hour?) or a week if there's a need for equipment or topology upgrades. And yes IPv6 is easy; easier than IPv4. Most network manufacturers now support IPv6 out of the box. If your old router does not support IPv6, most likely there will be firmware upgrade that would fix this problem. But of course to get wirespeed IPv6 switching and routing, you would need a hardware upgrade if that capability is not already present in your device.

Re:easy?

[holophrastic]

That's a big falacy. Google has all of it's stuff in one place, and with the scale and redundancy to maintain it all without taknig things down. I'm a small web company. I have more "products" than google, and more distinct clients than google. For me to upgrade some software, I need to talk to every client that uses it, I need to convince them to buy new hardware or adjust their existing hardware. I need to teach them how. I need to convince them that it's beneficial in the first place. Then I need to change dozens of projects being used by nearly one hundred clients without taking anything down.

Every one of my clients says the same thing: "I'm running a business here. I don't have time to redo things that work.".

So when ipv4 stops working, then I'll be able to convince them. Same goes for me, by the way. I have nothing to gain by switching to a new protocol. The old one works fine.

Re:easy?

[profplump]

How many of your products do anything at all with the IP address? Seriously, TCP works the same way over IPv4 as IPv6, so unless you're writing 40 versions of a network stack or something that reads IP address for something more complicated than checking that old.address == new.address, I don't see how much testing you'd need outside of the network itself.

Re:easy?

[Anonymous Coward]

In a lot of companies, 18 months of labor would still see them piddling around with Use Case diagrams, much less 4 months solid. And I know companies smaller than Google that routinely spend more than 4 months on non-revenue generating projects. Sometimes because an outside agency made them so so, sometimes because the revenue-generating projects won't run without them.

Then again, I worked in one organization where the CEO couldn't understand why he couldn't just fire the whole mainframe OS support team. After all, THEY weren't "Revenue Generating".

Re:easy?

[rthille]

Bah, if Google had done it right in the first place, it'd have taken one guy updating a couple/few libraries!

Re:easy?

[TheRaven64]

If you're Google, you have a very small market share in China, and are desperately trying to increase it. Consumer connections in China are going to be IPv6 or double-NAT'd IPv4 (so most things that punch holes in NAT won't work) very soon due to the way in which v4 addresses are allocated. Being the first service to work on China's v6 network is going to give them a big advantage in a rapidly-growing market.

Re:easy?

[AliasMarlowe]

Spoken like someone without a PhD. What you say is true only where the value of 'everything' is defined as 'procrastination'.

And if anyone on the team has TWO PhDs, then even procrastination becomes mind-bogglingly difficult.

Re:easy?

[cenc]

Yea, but do they have a wife that will kill them if her torrents quits working?

In fact I would like to conduct a survey of how many of those Google engineers switched their wife's connection to IPv6.

Re:easy?

[Scrameustache]

How big is Google's network compared to most companies?

Erm... Epic?

The hardest part of deploying IPv6 is actually getting IPv6 network transit... Very few ISPs will offer it, or charge a high premium for it ontop of their ipv4 charges such that it isn't worth the expense.

Well there's your problem right there.
It's not that it's hard, it's that people would punish you if you tried.

Re:easy?

[Anonymous Coward]

"Difficult" (or "easy") and "time-consuming" are entirely orthogonal, actually.

Running 100 meters in less than 10 seconds is difficult, but it's not time-consuming (although preparing for it might be). Writing "this is boring" one million times would be time-consuming, but not difficult.

Re:easy?

[mikkelm]

Every IPv6 prefix you add to your FIB is four times as expensive as an IPv4 prefix.

Re:easy?

[Anonymous Coward]

Time and ease are independent. Walking across the country takes a long time, but isn't hard. Bench-pressing 500 pounds is very hard, but won't take long.

Remember that the average result of a software project at a company that has tens of thousands of employees is "sputters along for a couple years, and then dies".

An IPv6 migration does sound easy to me. Each piece is basically independent. You can stop at any time, and be no worse off than when you started. It's probably highly parallelizable. Since many of your programs are probably open-source, you can get help from a huge pool of outside people.

It sounds like the world's easiest 18-month software project to me.

Re:easy?

[Cramer]

It didn't take 11 years to "build". As with anything designed through committee, it goes round and round for years until everyone's personal/politcal agenda and ego are satisfied -- the core of the protocol was on paper a long time ago. And what we get is a flaming f'ing mess that completely ignores the way people actually use IPv4 today with no interoperability or migration path and next to zero reason for anyone to even think about switching.

Re:easy?

[Cramer]

Sadly, this is not the case for a lot of people. Unless you have hardware that's only a few years old, the odds of whomever built it adding IPv6 to it are slim. I have mountains of perfectly functioning equipment that will never have IPv6 support, and most of it is not "ancient". Technology advances quickly and companies abandon products ("legacy") after just a few years. Add to that companies being bought or otherwise going out of business.

Re:easy?

[PeterBrett]

Spoken like someone without a PhD. What you say is true only where the value of 'everything' is defined as 'procrastination'.

Finally! Someone who understands postgraduate education!

Re:easy?

[eonlabs]

For example, and I'm not sure if this is true everywhere, attempting to log onto a comcast broadband connection with IP6 enabled on a windows adapter has failed me every time. This was not true when I attempted the same on Time Warner or Cable vision networks. If major parts of the internet backbone still need to support it, it may be a while before it really gets to a self sustainable level.

Re:easy?

[generica1]

That's BS. They CAN be replaced but people are simply inflexible and corporations in particular get very scared of change when it comes to IS/IT. Software in 2009 can do anything software in 1979 could do, only better. Your analog modems are legacy equipment and they are there to support the PEOPLE who insist upon them - there ARE better solutions than merely kludging legacy support into every possible corporate upgrade. Ditch the old, get better stuff!

For example, a fully functional legacy PC system with analog serial ports etc. could be implemented entirely in software including an analog modem that handles DSP via the host, and the phone line via VoIP, and then virtualized on a server somewhere, and the physical legacy analog crap could be tossed out. But humans (i.e. workers familiar with the legacy system, as well as upper management) will NOT just jump on board to ideas like this without a lot of resistance. That doesn't mean they aren't do-able. The above example is still implementing the legacy solution, but not using legacy hardware. There is probably a much more elegant (albeit completely hypothetical as per this discussion) solution that ignores the legacy equipment, and if the corporation as a whole switched over to the new solution en masse, there would be no need for the legacy system.

The block is ALWAYS people when it comes to implementing technological upgrades within corporations. It's rarely the technology. Technology is easy to replace/toss out and re-implement. People are much harder to organize and manage than technology.

Oh... and is Google not a "real corporation" now? I am surprised by that statement. They are definitely young relative to corporations from the 18th century that may still exist, but they are not new kids on the block in their field. In addition, I would suspect their network and their tech footprint greatly exceeds that of the average "real corporation", and encompasses a lot more than what a company who doesn't specialize in online information indexing / data mining would need.

Re:easy?

[sexconker]

Systems can be replaced, sure, at enormous cost and effort.

"The reality is there are TONS of legacy systems out there that can NOT be replaced with any currently available "solutions"."

Note the "currently available" qualifier - it means that you'd have to hire some developers to figure out your old system, make a new one, transport all the data, and handle the transition seamlessly.

Simply NOT going to happen.

The bottom line is there is no fucking incentive for corporations to make the switch.

Re:easy?

[Anonymous Coward]

Who says everything has to be replaced with IPv6, isn't it backwards compaitable?

Re:easy?

[MadAhab]

A lot of corporations say that just before the aging, expensive legacy technology they can't do without goes permanently tits-up, or gets replaced by a small, intelligent team.

Re:easy?

[MadAhab]

Less forgiving? I have to call BS on that one.

No one is less forgiving than the general public paying nothing.

I award you one Fail Whale.

Re:easy?

[Koutarou]

True, however having at least a v6 /32 (minimum allocation from an RIR) to work with means you have plenty of space to aggregate properly so a typical device will see a lot less of them.

Re:easy?

[dbIII]

About the only large building you can get from the idea to construction in less than four months is a circus tent. That fits well with people that have the above attitude :)

No, I don't think you are stupid I just think you are over-generalising. However I have met managers that actually did believe it applies in all cases and they were complete clowns with short term success and long term failure.

Re:easy?

[daniel23]

pirate bay supports ipv6:

3.511.154 registered users. Last updated 03:10:04.

IPv4 18.113.972 peers (8.726.310 seeders + 9.387.662 leechers) in 1.604.503 torrents on tracker.
IPv6 32.210 peers (15.477 seeders + 16.733 leechers) in 31.800 torrents on tracker.

Re:easy?

[Repossessed]

There are sometimes compatibility issues with moving to something new.

I've spoken to one company who uses windows 98 machines, because their inventory system is on legacy software that requires windows 98, and the company who made that software went tits up. Since the software uses a proprietary binary format, its beyond the means of the company to switch to something new, even though there are affordable, and better, options.

This incidentally, is my biggest reason to push for FOSS, or at the least open standards, in the workplace, if you don't control the code, you can get royally screwed, either from a company going under, or declaring that your updates now cost 3 grand a license, even MS has dropped support for a format they created a time or two.

Re:easy?

[Anonymous Coward]

You've never worked in a standard IT company then. 18 months is _fast_

Re:easy?

[mellon]

Speaking as a geek myself, I would just like to point out that a common mistake we geeks make is factoring out the human factors problem. "If only everyone were reasonable" is not a good grounding assumption.

Another point, which is really more relevant to what you've said, is that it's not always cheaper to upgrade. A legacy app that works well and does not need enhancements may be safer and more secure than a new app that replaces it, despite great effort to make the new app safe and secure. This is not because the new app programming environment isn't as good as the old one - it's because the old app and the old environment have been around for thirty, forty, even fifty years, and the bugs have been ironed out. Tossing that and replacing it with something different is not to be done lightly.

However, my main response to what you've said is that in fact the person you're correcting was wrong for a different reason. That reason is that you don't need to change the legacy systems. Switching to IPv6 doesn't mean you have to update all your mainframes to do IPv6. Leave them with IPv4, and do protocol translation. They will never know the difference.

Re:easy?

[mellon]

A web service provider doesn't force their customers to upgrade. Rather, if you *provide* IPv6 connectivity, your customers may *choose* to upgrade. You don't have to sell them on it - they will do it when they do it. But if you don't provide the functionality, then they won't have that choice.

Re:easy?

[Anonymous Coward]

all of it's stuff

"its".

Re:easy?

[TheLink]

The problem doesn't go away for FOSS.

Once you have a big system, it's YOUR SYSTEM itself that is the biggest "problem" for you. Not whether it's on OSS.

For example, say some years ago someone built a huge complex system that somehow was reliant on MySQL 3.x (because it appeared to be the least bad choice at that time - e.g. postgres95 was too slow, Oracle = $$$$$, etc).

Now the system works, with known bugs and known workarounds, and worse, with lots of stuff that's custom made to deal with the deficiencies and bugs of MySQL 3.

As a result, it is going to cost a lot to migrate the system to a more recent version of MySQL, or some other DB. Development, testing, extra hardware, time, lost productivity.

Analogy: if you only build a small hut on top of FOSS, moving it to something else is a small problem. That changes once you build a big factory on it.

If the company hasn't budgeted for the cost of upgrading, then it's stuck with the old software.

There's plenty of FOSS out there that has a poor record for backward compatibility, and poor support for old versions.

Yes the upgrades might be free, but you can't use them till you figure out what you have to change in your million-lines-of-code system.

Re:easy?

[Ritchie70]

I've actually been having this conversation at work a lot lately with a certain group.

They don't seem to understand that we are operating within a business, and there is no reason to pursue a technology just because it's cool. If there is no business benefit then it should not be done.

In the case of a critical older system on its last legs, addressing its impending failure before it fails is a business benefit. If what it does is critical you must have a disaster plan.

In the case of a legacy system running on older hardware that can fairly easily be replaced, or that you have a closet full of waiting as spares, the risk is addressed. As long as it meets the business need it should be left alone. Just because it's old doesn't mean it's inherently bad.

Most businesses aren't in the business of having their employees play with cool new technology. They're in the business of their business.

Re:easy?

[generica1]

I wasn't disputing that there was or was not an incentive, I was disagreeing with your statement that it was a lot of work and/or not possible.

Specifically these statements:

To get a real corporation on IPv6 will takes years of constant work, and even then you'll still have legacy systems hooked up to analog lines doing whatever it is they do on their data/fax modems.

The reality is there are TONS of legacy systems out there that can NOT be replaced with any currently available "solutions".

Clearly, if a company has a motivation to move to IPv6 it will not take years of constant work, as Google has just demonstrated.

Conversely, there are NOT tons of legacy systems that can NOT be replaced. They are just being left alone because the owners of them have no reason to upgrade them. "can not" is not the same as "will not".

That's all.

There will be no business incentive for the average corporation until IPv4 runs out of addressing space, and those who have already switched at that point will be laughing and taking the weekend off while other businesses scramble to regain basic connectivity. For some (i.e. Google), that is enough incentive right there, as their sites need to be universally connectable for their business model to work.

Re:easy?

[Repossessed]

Open formats are the key, not open source, open source just means open formats are the default position.

Re:easy?

[sexconker]

Read.
The reality is there are TONS of legacy systems out there that can NOT be replaced with any currently available "solutions".

CURRENTLY AVAILABLE.

Are all those fortran programs are around simply because people are too lazy to switch over to the C/C++/web versions that were written?

(Since you won't get it, the answer is NO. Those fortran programs are around because there is NO replacement. One can be written, sure. But we have working shit already, why add cost, time, and disruption for zero gain?)

Re:easy?

[generica1]

No, I don't "not get it", I just think you're wrong. It's not that there is NO REPLACEMENT for this completely hypothetical Fortran code. It's that there is nobody paying anyone to WRITE the replacement code. If the code is not currently available, it does not mean that the solution does not exist. Therefore, the currently available solution in your example is to WRITE THE CODE. Which is 100% possible.

Since you asked: Why would you replace a legacy system? Lots of reasons. I guess that if one is finding themselves in the situation where they are considering replacing a legacy system, that perhaps there may be a few reasons already on their mind. We are talking about replacing legacy systems with systems that are compatible with IPv6 which to me would mean that a compelling reason to convert a legacy system in this example would be 'to regain/retain future network connectivity'. For example. Is the ability for your old legacy app to remain on the network worth your company's time? At some point it is going to be UNLESS YOU REPLACE IT with something non-legacy. Either way you are addressing the same problem, it's just a matter of when.

To stick with your example further, it's not like Fortran does something that is absolutely inimitable by any other language or platform. But who cares? Fortran can exist on a non-legacy platform, and fulfill the legacy function without legacy hardware. GNU Fortran compiler, for example, doesn't even compile machine code directly, it compiles assembly language. So one could write the replacement for the legacy Fortran system in optimized assembler if one wanted to. Just because nobody is paying for that to happen does not mean that it is not possible.

Again: "TONS of legacy systems out there that can NOT be replaced with any currently available 'solutions'" is simply not true. The solutions are there (i.e. write/build/outsource a replacement), they are just not being pursued because of a lack of business incentive. This is shortsighted, and will change, when considering IPv6.

Re:easy?

[sexconker]

You still can't fucking read you retard.

There is no currently existing replacement for a lot of fucking programs.

Developing a new system as a replacement means it is NOT a CURRENTLY EXISTING replacement.

Creating replacements costs time and money and often results in downtime or time when both systems have to be maintained simultaneously.

If you think that such systems are "hypothetical", you are an idiot.

Re:easy?

[generica1]

You are sure angry about something that I can't quite figure out. You've got some serious attitude, buster. Why are you resorting to profanity and name calling? Argument fall apart much?

The reality is there are TONS of legacy systems out there that can NOT be replaced with any currently available "solutions".

This is false. Name one.

If you think that such systems are "hypothetical", you are an idiot.

Ahhh, right, it's hypothetical. OK, so be specific. Google upgraded their existing platform and all of their applications to be compatible with IPv6. So, I have an example of a legacy system that WAS replaced without any downtime and without having to create new solutions.

Just 'cuz some dusty old server in a corner at some corporation hasn't been touched in 20 years and nobody knows what it does anymore, doesn't mean the world will implode and all will go down in flames if the server is decommissioned. Analyze, brainstorm, plan, and create a replacement that encompasses the input and output of that legacy system using existing tools ... and ta-da!

CAN NOT be done is not the same as WILL NOT BE DONE.

Replacing a legacy system is re-inventing an existing wheel, not creating a new wheel that "SIMPLY CANNOT BE IMAGINED!!! OMG!"

Re:easy?

[generica1]

(typo - should have wrote "it's not hypothetical" not "it's hypothetical" above.)

Re:easy?

[sexconker]

You are a moron who does not understand the phrase "currently existing".

I will not provide you with dozens of articles over the past years detailing trends for the increasing need for coders of legacy languages, such as FORTRAN and COBAL.

Since you can not read or understand anything I write, I will no longer respond to you.

Re:easy?

[generica1]

You're hilarious.

The Real Problem?

[Anonymous Coward]

Correct me if I'm wrong, but isn't the real problem convincing the ISPs to enable IPv6? I've been enabling IPv6 on machines for years now, for all the good it's done me. The packets rarely make it out of my network, and that's only when the border router agrees to traffic IPv6.

Re:The Real Problem?

[GiMP]

Yes, I think this is the biggest barrier to adoption, and I'm not just talking about for residential connections. I was recently hunting for IP transit in center-city Philadelphia and found that very few carriers provided IPv6. For now, we're playing "wait and see".

Re:The Real Problem?

[metamatic]

Well, it's not ideal, but 6to4 will give you automatic IPv6 connectivity even if your ISP only provides IPv4. That's what I did.

Re:The Real Problem?

[Tony Hoyle]

Works if (a) your provider routes 192.88.99.1 (many don't), and (b) the server you get at the other end isn't 3000 miles away..

OK you could live with (b) for experimentation, but it's not ideal. The go6 stuff is better for home networks if you can't get
v6 off your provider (ie. 99% of people).

At work we're behind a provider that blocks ipv6 at their border routers. They claim it's insecure, and refuse to remove the block... We just route our ipv6 over the VPN instead (we need it for testing, so it's kinda critical that it works).

Re:The Real Problem?

[jonwil]

The question is, why are you still with this particular provider if they are blocking something critical to your environment?

Addition to regular work?

[slummy]

Google engineers worked on the IPv6 effort as a 20% project -- meaning it was in addition to their regular work -- from July 2007 until January 2009.

Google allows it's employees to use 20% of their WORK DAY for personal projects. So technically this wasn't "extra" work.

Re:Addition to regular work?

[Anonymous Coward]

So you're saying my paid 15 minute breaks are work? That seems to be your definition.

Re:Addition to regular work?

[AliasMarlowe]

Google allows it's employees to use 20% of their WORK DAY for personal projects.

But that's the 20% that the rest of us spend drunk. Bad deal, evil Google!

Re:Addition to regular work?

[Tubal-Cain]

You don't have anything you want to learn or do that could make you a more productive employee if only you had the time to fiddle with it?

So it would take regular people what, 40 year?

[Dan667]

I can imagine some of the conversations that would happen at regular places of business. *shutter*

Re:So it would take regular people what, 40 year?

[Anonymous Coward]

I think you mean shudder, not shutter.

An elegant solution

[Sybert42]

Despite being an elegant and technologically sound solution, I think IPv6 will be adopted universally within a few years.

Re:An elegant solution

[camperdave]

Thanks for the new sig. I've attributed it to you in my journal, but the sig line is to short to do so.

Re:An elegant solution

[Frozen Void]

'The year of IPv6 on the network'

Re:An elegant solution

[riffzifnab]

The best part is that it's never out of date!

v6?

[Anonymous Coward]

damn, I haven't even gotten around to installing IPv5 yet, so I'm certainly not going to be loading v6 anytime soon!

Re:v6?

[4D6963]

You think that's bad? I'm still stuck with IPv3.11 for Workgroups!

Re:v6?

[MadAhab]

funny

Corporate users

[hwyhobo]

What about convincing many corporate users who have come to believe over the years that private IPv4 NATed networks are an essential part of their security?

Re:Corporate users

[Anonymous Coward]

What about convincing many corporate users who have come to believe over the years that private IPv4 NATed networks are an essential part of their security?

Already taken care of.

Private Addresses in IPv6

Re:Corporate users

[idiotnot]

NAT (or more correctly in most cases PAT) is not a security feature.

More pushback comes from security-mastar types, who've been trained in an IPv4-only world. IPv6 forces them to do two things they hate doing: a) properly secure perimeter devices, and b) ensure that each host is secure.

A lot of it, of course, stems from the Win9x/NT4/2k days, when outbreaks on internal networks caused major business disruptions.

Re:Corporate users

[Tony Hoyle]

You don't need that most of the time (everything on the network segment has an fe80:: address anyway), only to proxy or NAT the outgoing connections. IIRC the ipv6 NAT solutions that exist are basically 1:1 rather than 1:M so they're not equivalent.

Re:Corporate users

[metamatic]

You don't need that most of the time (everything on the network segment has an fe80:: address anyway)

Unfortunately, fe80:: addresses are link-local, so they require the interface as part of the address in order to disambiguate them; e.g. fe80::1:1%eth0. And there's a lot of software that claims to be IPv6 aware, but doesn't understand addresses in that format.

Re:Corporate users

[Tony Hoyle]

A truly ipv6 aware app shouldn't be parsing the format itself anyway.. it should be calling getaddrinfo with the string as entered.

Otherwise if the format changes in the future we'll have to go through this whole thing again.

Re:Corporate users

[Tubal-Cain]

Why do your users know or care about the existence of NAT?

Re:Corporate users

[hwyhobo]

Misunderstanding: I meant corporations as users, with some NetAdmins seeing NAT as part of their security measures (yes, there is a good degree of that thought out there).

Re:Corporate users

[growse]

Beat them round the face and tell them they're doing it wrong?

I'd *love* to see a virus or worm that exploits those who have NAT as a critical security measure, and doesn't affect those who know what a firewall is, and how to use it properly. If only to get people to do things properly.

Re:Corporate users

[__aaxwdb6741]

They should be fired for incompetence.

It is technically very easy

[guruevi]

It's very easy to do. Most if not all servers are currently IPv6 compatible and most of the software has this type of stuff abstracted away by the operating system.

Then all you need to do is ask your provider for an IPv6 range and put some records in your DNS, enable your clients for IPv6, tell your routers that they'll from now on see IPv6 addresses as well (usually already in the firmware or it's in an upgrade somewhere) let your DHCP server give out IPv6 addresses and then you're done. Add an IPv4 to IPv6 gateway if your provider doesn't support IPv6 yet.

This all can be done in several steps and IPv4 can keep chugging at the same time as well so there is practically no downtime to the systems. It's the same as adding an IPv4 range to your network (if you ever run out of space in your range) except that there are more digits and that some of your older hardware needs a small upgrade.

The problem is that it requires manpower to do so which isn't cheap. In an organization like Google it takes a group a while at 20% of their time. In many organizations, those groups are 1) not as competent, 2) don't have 10% of free time, let alone 20%, 3) this has to be justified as far as manpower costs go.

Re:It is technically very easy

[morgan_greywolf]

Then all you need to do is ask your provider for an IPv6 range and put some records in your DNS, enable your clients for IPv6, tell your routers that they'll from now on see IPv6 addresses as well (usually already in the firmware or it's in an upgrade somewhere)

I was with you until the bold portion. The thing is, if you are running enterprise-grade equipment, great. Many SOHO businesses, OTOH, are using consumer routers. Most of these do not support IPV4 OOTB and are not capable of being an IPV4-IPV6 gateway without modification.

SOHO users may be better off building a firewall/router out of a cheap PC. Home users are kind of out of luck unless they are tech savvy.

Re:It is technically very easy

[Chabo]

Yeah, and the Wife Acceptance Factor of a new router probably won't be high for many people.

"You can get the new router, but that means you can't get any more computer hardware this year."

Re:It is technically very easy

[rabbit994]

When talking about Windows server, which in most businesses is Operating system your talking about, only 2008 is IPv6 100%. 2003 is not 100% IPv6 and some stuff must be done either via config files or command line. Not that this is bad thing but when your looking at GUI Console, you don't see IPv6 information which could lead to confusion. Easy example is that 2003/XP look up AAAA DNS records over IPv4 instead of IPv6. Also, Active Directory over IPv6 is not supported as well. Vista and Windows 7 support IPv6 natively along with Windows 2008. Till those operating systems are largely used in Enterprise, we will still see IPv4 being rolled out.

My guess is IPv6 will not see wide adoption in United States till IPv4 addresses are completely exhausted and their price skyrockets which should happen around 2011/2012. Native IPv6 deployments (where IPv4 address are not given to clients) till 2014-2016.

Re:It is technically very easy

[_avs_007]

It's very easy to do. Most if not all servers are currently IPv6 compatible and most of the software has this type of stuff abstracted away by the operating system.

You can't generalize all companies this way. Sure, Windows Vista and Windows 7 have IPv6 integrated in, and the OS abstracts the IPv6ness away from you, but that doesn't mean your problems are solved...

For example, Vista supports IPv6 out of the box while XP doesn't. Does this mean that simply upgrading your box from XP to Vista, and moving your apps over, is enough to make your apps IPv6 capable?

But anyways...

1. Windows XP uses a dual-stack to support IPv6, wheras Vista does not. Vista has one TCP/IP stack that does both IPv4 and IPv6. XP has two TCP/IP stacks, one that does IPv4 and one that does IPv6. To support IPv6 on this system, you'll need to bind to both TCP/IP stacks, and call into the correct modules, otherwise your code ain't gonna work with IPv6.

2.) What if you have to deal with embedded systems? Some of our systems are embedded, where everything is done in hardware. Much of this hardware does NOT support IPv6, because when it comes to fabbing chips, companies tend to want the lowest cost possible, so they will opt to not waste gates with IPv6 support if they don't plan on using it... It'll take some time to re-engineer these components, re-fab the chips, and re-validate the embedded system, etc.

3.) Just because the OS abstracts IPv6, does not mean the application does. What if your app expects to pass around IP addresses in dotted quad notation? What if somewhere in your code, it hard-coded the initializers for the sockets library to IPv4? What if you didn't map enough memory in your data structure to hold an IPv6 address? What if the change requires you to remap all your fields? That means every producer/consumer in that transaction chain will need to be updated and validated.

4.) All your infrastructure can support IPv6, and all your software can properly pass around IPv6 addresses, but that doesn't mean you are done... What if you have applications that use multicasting? IPv4 multicast addresses are not interchangeable with IPv6 multicast addresses. What if the change requires you to register a new multicast address with IANA? That's not a short process, believe me, I've gone through that process. So once you get this new IPv6 multicast address, you have to modify all your code to actually use it, etc. This can involve both software and hardware, as again, you could have embedded systems in the mix as well.

Re:It is technically very easy

[fuzzyfuzzyfungus]

On the plus side, crap consumer routers have a nasty habit of dropping dead every 18 months, so you can deal with legacy hardware by just waiting.

Re:It is technically very easy

[morgan_greywolf]

On the plus side, crap consumer routers have a nasty habit of dropping dead every 18 months, so you can deal with legacy hardware by just waiting.

Funny, I've had my LinkSys WRT54G for about 2.5 years and it sti

Re:It is technically very easy

[russotto]

On the plus side, crap consumer routers have a nasty habit of dropping dead every 18 months, so you can deal with legacy hardware by just waiting.

Zyxel P334W and Netgear WAB102 dual-band access point. Both have been going for years, though I have had to replace the Netgear power brick twice, both times after electrical storms.

I doubt I'd need a new router for IPV6, either. I'd need a new modem/bridge from my ISP, and then I'd live dangerously and run on the Real Internet, with no NAT (actually I almost am now; a couple of my boxes are 1:1 NAT). Except my wife's PC, which I'd probably handle temporarily by routing it through my Linux box.

I'd probably need new wireless gear, though.

Re:It is technically very easy

[AliasMarlowe]

crap consumer routers have a nasty habit of dropping dead every 18 months

My SMC WBRP2804 has been persistently undead for almost 6 years.
Are you implying that it's not crap???

Re:It is technically very easy

[skeeto]

crap consumer routers have a nasty habit of dropping dead every 18 months

That's so true. Netgear and Linksys routers tend to die on me after a year or two. I got one once that died inside of 48 hours.

Re:It is technically very easy

[microbee]

most of the software has this type of stuff abstracted away by the operating system

The OS doesn't abstract IPV6. The application has to use the proper APIs to support IPV6 directly. For example, it cannot assume sockaddr is ipv4 only, and ultimately support both ipv4 and ipv6. It's never that easy.

Re:It is technically very easy

[Tony Hoyle]

Then all you need to do is ask your provider for an IPv6 range and put some records in your DNS, enable your clients for IPv6, tell your routers that they'll from now on see IPv6 addresses as well

I just parsed the whole sentence and assumed it was supposed to be a joke.

1. Ask your provider for an IPV6 range. lol. The response is likely to be 'IPwha?'
2. Put some records in DNS - if you run your own (good luck with this on 3rd party DNS).
3. Tell your routers about ipv6 - provided they're Ciscos or similar. Otherwise you're out of luck.

Re:It is technically very easy

[Anonymous Coward]

If you're that whipped, just buy it and don't tell her about it. It can sit there out of sight and she won't know the difference.

Re:It is technically very easy

[mibus]

You're also forgetting that you need to buy new routers that fully handle IPv6 (at the same level as IPv4, including full monitoring and everything). New load-balancers. Upgrade OSs, if you're running anything more than a few years old. Update all of those in-house apps that store IP addresses as 32-bit values, upgrade third-party apps that bind specifically to IPv4 addresses and don't support v6 ones in the config... I'm sure people can come up with plenty more :)

Once you have a reasonably sized organisation, IPv6 is not "very easy to do". (Unless, apparently, you're made up of PhD holders with 20% of their time unused by other projects :)

And yes, I'm involved in IPv6 tasks within the company I work for, and yes, these are real issues we're looking at. For something there isn't an income stream for, it's a reasonable amount of work IMHO.

Re:It is technically very easy

[__aaxwdb6741]

1. If they say "IPwha?" they should be put out of business. You're assuming that my ISP is computer-illiterate. I wouldn't trust a computer-illiterate ISP with my corporate network traffic. Would you?
2. If your DNS host doesn't support you entering whatever AAAA records, they are computer-illiterate and should be put out of business for providing a subpar product. You should look for a better DNS host, or even better yet, host it yourself.
3. If your routers don't support IPv6, which has been the official successor to IPv4 for ten full years now, you're running some very old and very bad routers. They're probably not even supported by the vendor by now, and keeping them in production is just asking for trouble.

Pardon my french, but your whole post assumes that nobody knows what the fuck they're doing. If that is the case, they should be doing something else instead of being dangerously incompetent.

Re:It is technically very easy

[rastos1]

The application has to use the proper APIs to support IPV6 directly.

All you need to do is to use AF_UNSPEC instead of forcing IPv4 in following piece of code.

struct addrinfo hints;
struct addrinfo *result=NULL;
...
hints.ai_family = AF_UNSPEC; /* Allow IPv4 or IPv6 */
...
err=getaddrinfo(host, NULL, &hints, &result);

No other changes needed to make your app IPv6 ready. IMHO.

Not easy, and not the core problem

[mgkimsal2]

Define 'small team' - 5 people? 200? What's a 'small team' at Google?

The fact that Google makes such a big deal about only hiring the best and brightest and PhDs and such also indicates this isn't 'easy'. If it took a team of people who are regarded to be the best and brightest in their industry, with numerous PhDs on the team (or at least at their disposal on campus) *18 months* to do something (even part time) that still means that this is going to be a bigger issue for most companies.

Consider that the bulk of Google's apps that would need to be 'converted' have been written in the past 3-4 years (docs, maps, earth, etc.), and likely were written by people who put modularity and efficiency much higher than the average developer does (or is allowed to, in many cases) and you'll conclude that average developers who've inherited undocumented legacy code from previous average developers will have a much harder time than expected.

The core problem (as someone else pointed out) is consumer-level adoption - ISPs, routers, etc. It's somewhat chicken and egg, and perhaps having Google announce 100% support for it, this will give other players in the field the encouragement to put more effort in to transitioning over.

Lastly, why didn't Google (of all companies) bake IPv6 in to these main apps when they were first written?

Re:Not easy, and not the core problem

[ewenix]

Lastly, why didn't Google (of all companies) bake IPv6 in to these main apps when they were first written?

Perhaps the best and brightest spent 18 months of extra time on the massage table and drinking smoothies.
Then recently edited the .conf to include the line $IPV6 = 1;

Re:Not easy, and not the core problem

[D Ninja]

Lastly, why didn't Google (of all companies) bake IPv6 in to these main apps when they were first written?

Because, just as you said, Google hires the best. These guys needed a challenge. They gave themselves one.

(I'm kidding.)

Re:Not easy, and not the core problem

[Nimey]

The core problem is ISPs getting off their duffs to support IPv6. I'm ready for it at home (save for an old cable modem), but my ISP doesn't yet support DOCSIS 3.0 and IPv6, and this is a common problem.

Re:Not easy, and not the core problem

[ivicente]

Lastly, why didn't Google (of all companies) bake IPv6 in to these main apps when they were first written?

What? And miss all of the Slashdot hype for making the 4->6 conversion?

Re:Not easy, and not the core problem

[sharkey]

Define 'small team' - 5 people? 200? What's a 'small team' at Google?

Brin, 2 Asian hookers (1 Thai, 1 Vietnamese), the pilot and the copilot.

Re:Not easy, and not the core problem

[syousef]

Exactly.

Call me when Google uses a "small team" to convert a couple of hundred undocumented or poorly documented apps written in C and running on an old system like VMS since the mid-80s. Then I'll still have concerns about the business case during an economic downturn.

Re:Not easy, and not the core problem

[jgrahn]

The fact that Google makes such a big deal about only hiring the best and brightest and PhDs and such also indicates this isn't 'easy'. If it took a team of people who are regarded to be the best and brightest in their industry, with numerous PhDs on the team (or at least at their disposal on campus) *18 months* to do something (even part time) that still means that this is going to be a bigger issue for most companies.

I bet most other company networks don't look like Google's (for better or worse),

Consider that the bulk of Google's apps that would need to be 'converted' have been written in the past 3-4 years (docs, maps, earth, etc.), and likely were written by people who put modularity and efficiency much higher than the average developer does (or is allowed to, in many cases)

Where in TFA or Google's PDF do you find anything about converting applications taking much of the time? I doubt that was needed -- but it is likely that they had to test the applications, if they had never been used with IPv6 before.

and you'll conclude that average developers who've inherited undocumented legacy code from previous average developers will have a much harder time than expected.

I suspect most of the application work was reconfiguring, and comparable to the work it would take to switch to another IPv4 network range. Finding those odd, yet vital, scripts with hard-coded IP addresses in them, and so on.

(I say suspect, because I've only done vaguely similar things.)

Re:Not easy, and not the core problem

[Phs2501]

Use a IPv6 tunnel broker until your ISP gets with it. It will not be as fast as your "raw" connection, but it will get you started and get you important experience. Most of the tunnel providers seem excited to expand IPv6 usage.

Re:Not easy, and not the core problem

[Tony Hoyle]

'small team' generally doesn't go over about 5 people. You simply can't - as a team gets larger it gets less efficient. This is true even for google.

http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Re:Not easy, and not the core problem

[gnud]

How about leaving these apps on an internal IPv4 net?

Re:Not easy, and not the core problem

[xaxa]

On Ubuntu (so presumably Debian too) I just did
aptitude install miredo
invoke-rc.d miredo start

Then it just worked:
$ ping6 ipv6.google.com
PING ipv6.google.com(2001:4860:a003::68) 56 data bytes
64 bytes from 2001:4860:a003::68: icmp_seq=2 ttl=60 time=37.8 ms

wget -6 http://ipv6.google.com/

Re:Not easy, and not the core problem

[Chandon Seldon]

Call me when Google uses a "small team" to convert a couple of hundred undocumented or poorly documented apps written in C and running on an old system like VMS since the mid-80s.

Why would those systems need to get rewritten?

Re:Not easy, and not the core problem

[Nimey]

Sweet! Thanks.

Re:Not easy, and not the core problem

[syousef]

Old apps need to be able to communicate on the network too. They're not all isolated.

Re:Not easy, and not the core problem

[EdwinFreed]

Converting applications isn't that difficult in most cases. My team works on a large application with many components, and a single engineer was able to make it mostly IPv6-aware in about a month. It was mostly a matter of changing API calls around since the the IPv6 support is there in the OS.

The hard part comes when you actually want to test and deploy this stuff. Getting a lab setup for actually testing IPv6 required a protracted wrangle with the IT folks that took more time than the coding.

And the state with routers and other network-level pieces is NOT good. In particular, the lack of a decent SOHO-grade router/firewall with IPv6 support is a serious obstacle.

I am honored.

[Sybert42]

Thanks.

Re:Yep..

[fuzzyfuzzyfungus]

I suspect that having a comparatively short history, and thus not much legacy software(and little of that from third parties) probably makes life very much easier.

Re:Yep..

[just_another_sean]

Things are easy when you're GOOG

Yeah my first reactions was that this is a lot like Les Paul telling people that playing guitar is easy.

Gateway/Routers?

[Midnight Thunder]

Does anyone have a list of current networking hardware that is IPv6 ready? Specifically I am interested in any gateway/routers that support IPv6 out of the box, in the sub-$200 category.

I know about DD-WRT, but I don't want to have spend time hacking my router.

Re:Gateway/Routers?

[Zenzilla]

Hacking your router would take you less time than the time it took you to post.

Re:Gateway/Routers?

[Anonymous Coward]

That is the wrong question to be asking. Almost all new routers/switches support ipv6 out of the box, the question is how many of them support ipv6 in hardware at all. The answer to that question is undoubtedly a mcuh smaller set.

Re:Gateway/Routers?

[Conception]

No joke. It's just a firmware upload.

Re:Gateway/Routers?

[SBrach]

I have this router, it does ipv4 and ipv6 dual-stack and the built in VPN features are great.

Re:Gateway/Routers?

[powerlord]

Last time I checked the only one that supported it out of the box was Apple's Airport Extreme.

I've heard "the usual suspects" (Linksys, Dlink, Netgear) have added it since then, but I haven't been looking to confirm that, and I'm not sure if it ships enabled or not.

Re:Gateway/Routers?

[spinkham]

The best one I've seen so far is the Apple Airport extreme, offers easy tunneling service also if you don't have native IPv6 yet.

Re:Gateway/Routers?

[Anonymous Coward]

DD-WRT v24 with IPv6 enabled may be broken according to the Wiki. There are supposed to be fixes around.

Re:Gateway/Routers?

[spinkham]

For the home router segment, the traffic isn't high enough that it matters, and most of them don't support IPv6.
Of course with IPv6 the home router is no longer important really as NAT will no longer be necessary, but it will still nice for Joe Clueless User to have a hardware firewall appliance anyway I guess...

Re:Gateway/Routers?

[Midnight Thunder]

No joke. It's just a firmware upload.

And making sure your router can support a third-party firmware.

Re:Gateway/Routers?

[BikeHelmet]

He'll spend the same amount of time updating the firmware on whatever he buys. Whether he updates it to alternative router firmware, or official firmware, it still (likely) has to be updated from whatever it shipped with.

Re:Gateway/Routers?

[smoker2]

Let me know when you've got completely secure gigabit wifi.

Re:Gateway/Routers?

[Denis Lemire]

Apple's Airport Extreme supports IPv6 beautifully. :)

Re:Gateway/Routers?

[Eil]

There's nothing you can do right now to automatically "switch on" IPv6 across your whole Internet-connected network. There is effort involved because practically nothing supports it out of the box. (Read the zillion chick-and-egg comments in this and every other IPv6 article.) If using IPv6 were easy right now, this Slashdot article--and all of the other ones before it--wouldn't exist.

Re:Gateway/Routers?

[99BottlesOfBeerInMyF]

Does anyone have a list of current networking hardware that is IPv6 ready? Specifically I am interested in any gateway/routers that support IPv6 out of the box, in the sub-$200 category.

It depends upon what you mean by "supports IPv6". That can everything from supporting the protocol to working well with existing consumer OS's and tunneling IPv6 if your ISP is not supporting it. Also, you should look at what features are supported by IPv6, like does using it bypass your router's firewall?

The most practical I've seen are OpenWRT routers and Airport Extremes.

Re:Gateway/Routers?

[tukia]

Try looking in the approved lists on http://www.ipv6ready.org/

Re:Gateway/Routers?

[chihowa]

DD-WRT does not support IPv6 out of the box, so to say. See here. It's not a huge deal to get it working, but it's not for your grandma to do and would probably intimidate an embarrassing percentage of Slashdot regulars.

Re:Gateway/Routers?

[spinkham]

1) "Complete security" doesn't exist.
2) I fail to see how that relates to the needless status of the home NAT router. With IPv6, your ISP can give you your very own public IPv4 sized address space, and you only need a switch instead of a NAT router. It is likely that NAT won't die for quite a while though, and even then people may still opt for a stateful hardware firewall, but IPv6 makes them purely optional. See http://www.ietf.org/rfc/rfc4864.txt

Re:Gateway/Routers?

[Tony Hoyle]

That says nothing about whether ipv6 is supported on the available firmware.

eg. the Billion Bipac 7402 is listed as ipv6 ready. It does *not* support ipv6 and Billion have given no indication that it ever will. They tested an internal firmware that was never released.

I've no reason to believe any of the other entries are any more useful.

Re:Gateway/Routers?

[Tony Hoyle]

A switch? lol. Good luck connecting that to your phone line..

You need a router whether you have ipv6 or not, because you need its firewalling capabilities.

Re:Gateway/Routers?

[spinkham]

Modems, media converters, and routers are different devices. You'd still have a cable/DSL/POTS/WIMAX modem or fiber media converter, but not necessarily a router.

Routers and firewalls are different devices. It just happens that a NAT router approximates a stateful firewall, but that's not the best or only way to do it.

Yes, Joe Q Public might be better off with a stateful firewall appliance then a simple switch, but IPv6 kills the need for a home NAT router. I prefer individual host hardening to depending on a firewall, but the belt-and-suspenders technique is best for most people.

Re:Gateway/Routers?

[Tubal-Cain]

What about us that don't have a router that is explicitly supported? (version number is diffrent)

Re:Gateway/Routers?

[Anonymous Coward]

m0n0wall has ipv6 support. Just get a cheap router like Alix

Re:Gateway/Routers?

[Midnight Thunder]

Routers and firewalls are different devices. It just happens that a NAT router approximates a stateful firewall, but that's not the best or only way to do it.

Certainly, but when is comes to the home market or the small business market, the ideal device is something that does both. Anyone selling an IPv6 router for the home market would be mad not to include a basic firewall. Given the existence of ip6fw, it is just a question of providing the appropriate web UI.

Re:Gateway/Routers?

[Koutarou]

Yamaha's consumer broadband router line has supported v6 for at least 5 years.

Re:Gateway/Routers?

[Anonymous Coward]

http://www.apple.com/airportextreme/

Compatibility:
NAT, DHCP, PPPoE, VPN Passthrough (IPSec, PPTP, and L2TP), DNS Proxy, SNMP, IPv6 (6to4 and manual tunnels)

Re:Gateway/Routers?

[ion.simon.c]

Let me know when you've got completely secure gigabit wifi.

a) WTF?
b) IPSec + Kerberos goes a long way towards securing your network and the services on it. Being un-NATted allows you to use IPSec over the greater internet. :)

Re:Gateway/Routers?

[paul248]

Last I checked, the official builds of DD-WRT don't even support IPv6 anymore. It's always the first thing to go when flash space gets tight.

Re:Gateway/Routers?

[smoker2]

Did you read what I replied to ? The OP was saying we could get rid of routers. I have 4 machines off of 1 ADSL line. I don't want all 4 machines connected to the net as servers. Why do I need a public IP for all 4 machines ? And without a switch or router (which can be the same device) how do I connect 4 machines to my network ? Gigabit wifi ? Null modem cables ?

Re:Gateway/Routers?

[ion.simon.c]

Did you read what I replied to ?

I wonder if you read the entire conversation chain. Let's begin:

Midnight Thunder

Does anyone have a list of current networking hardware that is IPv6 ready? Specifically I am interested in any gateway/routers that support IPv6 out of the box, in the sub-$200 category.

I know about DD-WRT, but I don't want to have spend time hacking my router.

Anonymous Coward

That is the wrong question to be asking. Almost all new routers/switches support ipv6 out of the box, the question is how many of them support ipv6 in hardware at all. The answer to that question is undoubtedly a mcuh smaller set.

spinkham

For the home router segment, the traffic isn't high enough that it matters, and most of them don't support IPv6.
Of course with IPv6 the home router is no longer important really as NAT will no longer be necessary, but it will still nice for Joe Clueless User to have a hardware firewall appliance anyway I guess...

you

Let me know when you've got completely secure gigabit wifi.

Do you see why we're a little bit confused?

With NAT, who cares?

[HerculesMO]

Seriously?

I am in no rush to make this argument to my higher ups, as if I don't have enough work lately. NAT works fine for us and we support over 17,000 desktops.

Re:With NAT, who cares?

[slimjim8094]

NAT sucks because port forwarding sucks. If you're ever at an organization with enough IP addresses for users, it's like a breath of fresh air.

Most universities are like this. No fucking around with, well, anything. Want someone to download a file? Copy it to a directory, set up FTP on the directory, and give them your IP address. That was easy.

It's like how IP was supposed to work, after all - any Internet-routed IP address can route to any other Internet-routed IP address.

Re:With NAT, who cares?

[TheThiefMaster]

NAT is fine for desktops, but you'll be complaining quite a lot when IPv4 addresses run short enough that you have to start NAT'ing servers...

Re:With NAT, who cares?

[0racle]

IP was also supposed to work in an environment where you trusted everyone else. In the real world there will be at least one firewall between you and the rest of the world so you're not really cutting down on any administrative overhead.

There is nothing inherently wrong with port forwarding, it's not that much different then proxying. The problems that pop up are because of applications that are still being written like they are running on one big network where everyone is nice and trusts each other.

Re:With NAT, who cares?

[HerculesMO]

We don't have a lot public facing right now so for my position, I suppose I don't have a lot to worry about :)

I can see the logic, but for a company like Google where there's a LOT of public facing stuff, and for a person like me, it's really not an emergency, nor worth the effort.

Re:With NAT, who cares?

[Jonner]

You seem to be repeating the popular misconception that NAT is the same as firewalling. In fact, NAT makes firewalling much more complex than it should be and NAT adds no security to a properly designed firewall. You say "There is nothing inherently wrong with port forwarding, it's not that much different then proxying." Are you implying that for a host on one network to communicate with a host on another network, it should expect to always go through a proxy or port forward of some kind? Thankfully, that's nothing like the real Internet and I hope it never gets that bad.

Re:With NAT, who cares?

[0racle]

No I'm saying that simply going to IPv6 doesn't mean that everything in the world will be (or should be) freely available to everyone else. Yes, you no longer have to set up PAT, but you're still going to have to set up firewall rules; your administrative overhead hasn't really changed. You might not have a little Linksys doing NAT with IPv6 (though as I understand it you can) but unless you are a complete idiot, you are going to have a firewall.

There is nothing technologically wrong with port forwarding and yes every application that is to be used over the Internet should be able to operate behind either a NAT device or a Proxy because the developer never knows when it will be. Many ISP's already proxy their customers for cacheing purposes, most of those users never know that. Applications had better be able to handle that situation. I would consider an application in this day and age that can not handle being behind a NAT/PAT device or a proxy to be fundamentally broken.

Re:With NAT, who cares?

[smoker2]

I always thought there were lots of switches and routers that made the internet possible. After all, we can't all have a direct ethernet connection to every web site we visit, or email server we pop.

Re:With NAT, who cares?

[Tony Hoyle]

Yes there is. Port forwarding works provider you have *one* http server and *one* ssh server and *one* smtp server. It works for home networks.. it's a horrible hack even then.

There's a huge difference in the administrative load, because you don't have to start farting around with allocating new ports because the other one is used, or changing the forward twice a week because two different servers need to be available, and they have clients that can't change the destination ports (real world example).

Re:With NAT, who cares?

[xaxa]

IP was also supposed to work in an environment where you trusted everyone else. In the real world there will be at least one firewall between you and the rest of the world so you're not really cutting down on any administrative overhead.

If the users machine has IP 123.123.123.123:
"Hi, could you allow SSH access to my machine?"
Sysadmin unblocks 123.123.123.123:22 on the firewall.
"Done"

If the users machine has IP 10.10.10.10 and the organisation has the IP 123.123.123.123:
"Hi, could you allow SSH access to my machine?"
Sysadmin forwards 123.123.123.123:401 to 10.10.10.10:22
"Yes. People will need to connect to 123.123.123.123:401"

The first is easier, and also easier for users to understand.

Re:With NAT, who cares?

[dbIII]

doing NAT with IPv6

Somebody's brain just exploded and I hope it's not mine - NAT is only a way to deal with a lack of addresses.

Although the things often come in the same black box a firewall and NAT are completely different things. NAT has absolutely nothing to do with security, it's just a hack to route a lot of things through one address as well as it can. Because it can't do it very well it gives you the illusion of a security method simply because it is hard for things from the outside to know how to get in. The real firewall software built into even the cheapest ADSL modems blocks the same things anyway by default whether there is NAT or not.

It's also nice that you consider every piece of web server software that exists is "fundamentally broken" among a pile of other things.

Re:With NAT, who cares?

[Jonner]

Yes, IP routers make the Internet possible. Ethernet switches are nice, but not essential for the Internet. What does any of that have to do with the usefulness of NAT or firewalls?

Re:With NAT, who cares?

[Jonner]

I couldn't agree with you more. It's NAT that breaks the Internet, not applications that are broken. There are many complex and ugly hacks application protocols have to employ to get around the fundamental brokenness of NAT. Then Internet was designed as a peer to peer network, but the prevalence of NAT is a great obstruction to that ideal.

Though there are real technical difficulties impeding IPv6 adoption, I suspect ISPs are also dragging their feet adopting IPv6 because they will no longer be able to charge inflated prices for additional addresses and a move back toward the original peer to peer nature of the Internet would give power back to individuals and take it away from them. Or maybe I'm just paranoid.

Re:With NAT, who cares?

[cparker15]

Are you seriously complaining about having too much work? I'm sure some people here would be happy to take it off your hands...

Re:With NAT, who cares?

[HerculesMO]

I didn't have that problem until some people with not enough work were forced out of the company due to the economy.

and legacy stuff?

[misfit815]

Porting ongoing development efforts to IPv6 doesn't bother me in the least, even when you consider the impact of a non-revenue-generating task to be completed.

What I wonder is what we're going to do with all of that legacy software that's out of its support cycle. As a consumer, I'm worried that I'm going to have replace old, stable, DRM-free, purpose-built, paid-for software with bloated, memory-hogging, DRM-riddled, subscription-based junk just because nobody wants to make the old stuff work on IPv6.

Re:and legacy stuff?

[intheshelter]

I agree. IPv6 could really add some cool options to life, but I'm sure the government/corporations will screw it up and add all that crap to new devices.

A side note, would IPv6 eliminate some arguments against RIAA lawsuits? Taht would be the best way to get it implemented (not that I'm in favor of the RIAA) is to have them fund the transition.

And a tangent: Pretty gutsy quoting the bible on /. I'm surprised you haven't been crucified yet (no pun intended) because folks on here don't take kindly to that.

So big, we have to use maths

[ircharlie]

This made me laugh. From TFA:
"
IPv4 uses 32-bit addresses and can support approximately 4.3 billion individually addressed devices on the Internet. IPv6, on the other hand, uses 128-bit addresses and can support so many devices that only a mathematical expression -- 2 to the 128th power -- can quantify its size.
"

Re:So big, we have to use maths

[fuzzyfuzzyfungus]

I, for one, prefer sizes that cannot be quantified by mathematical expressions.

Re:So big, we have to use maths

[Anonymous Coward]

Well the part you quoted did say "qualify" not "quantify". In other words, the amout of individual addresses available in IPv6 is beyond the numbers even many scientists and economists are comfortable using.

Re:So big, we have to use maths

[Spyder0101]

2^128==3.40282366920938463463e38

Re:So big, we have to use maths

[Quietust]

Or, if you like big numbers with lots of commas, 340,282,366,920,938,463,463,374,607,431,768,211,456 (compared to the 4,294,967,296 in IPv4). Of course, a very large number of those (but still an insignificantly small fraction) are reserved for various purposes and cannot be used for normal addresses, but the same is true for IPv4.

Re:So big, we have to use maths

[SnarfQuest]

Can you give us those numbers in terms that are in common usaage? Like LOC (Libraries of Congress), GB (Golf Balls), DTM (Distance to moon)

Re:So big, we have to use maths

[Anonymous Coward]

So does your mom.

Re:So big, we have to use maths

[nog_lorp]

Sorry, I cannot allow you to post that. That number is impossible to write.

Re:So big, we have to use maths

[Anonymous Coward]

340,282,366,920,938,463,463,374,607,431,768,211,456 addresses

Re:So big, we have to use maths

[AliasMarlowe]

Can you give us those numbers in terms that are in common usaage? Like LOC (Libraries of Congress), GB (Golf Balls), DTM (Distance to moon)

OK, 2^128=3.40e38 approximately.
For comparison, 1e26 is approximately the number of Angstroms in a light year. The observable universe is about 1.4e10 light years in size. So the size of the observable universe is about 1.4e36 Angstroms. The number of IPv6 addresses is about 240 times bigger.

Re:So big, we have to use maths

[AliasMarlowe]

Forgot to mention: the number of IPv4 addresses is about the same as the number of Angstroms in 16inches. Just for comparison.

Re:So big, we have to use maths

[Anonymous Coward]

I agree. IPv6 does not have enough addresses. We need a system that has at least the busy beaver of 7 addresses.

Re:So big, we have to use maths

[lennier]

"IPv6, on the other hand, uses 128-bit addresses and can support so many devices that only a mathematical expression -- 2 to the 128th power -- can quantify its size."

Except that in the standard IPv6 addressing scheme, we immediately throw away 64 of those bits and use them as host identifier. Then we divide the rest heirarchically up into networks, each division of which can leak addresses. We probably won't be seeing a lot of 2-bit subnets for point-to-point links, as we have now in 32-bit CIDR; they'll grab 8 bits instead 'just in case'.

Since every network operator will think 'it's okay, I can be sloppy because 64 bits is enough for everybody', I'm sure it will be perfectly possible to get address space exhaustion in IPv6.

Re:So big, we have to use maths

[Yaotzin]

If each address was a dollar, you could buy approximately 1,546,738,031,458,811,197,560,793,670 cars with it (assuming the cost of the car to be USD $22,000). Though there might be some kind of discount when buying that many at once.

Re:So big, we have to use maths

[againjj]

This made me laugh. From TFA: " IPv4 uses 32-bit addresses and can support approximately 4.3 billion individually addressed devices on the Internet. IPv6, on the other hand, uses 128-bit addresses and can support so many devices that only a mathematical expression -- 2 to the 128th power -- can quantify its size. "

I guess 340 undecillion is a mathematical expression.

Re:So big, we have to use maths

[againjj]

If you had a bag of 2^128 GB, then the width of that bag would be about 1.05 DTM (assuming the densest possibly packing, and that the bag was basically spherical). Notes: 1 GB = 42.67 mm, DTM = 3.84x10^8 km.

Re:So big, we have to use maths

[Anonymous Coward]

Hierarchically, Lenneir

Re:So big, we have to use maths

[jonaskoelker]

I, for one, prefer sizes that cannot be quantified by mathematical expressions.

Then it might interest you to recall that the real numbers are uncountable and in the same breath learn that the definable numbers are countable.

See http://en.wikipedia.org/wiki/Definable_number

The short version: there are in fact numbers which can't be quantified by any mathematical expression.

Re:So big, we have to use maths

[kolcon]

How dare you post the key to my new encrypted DMCA-protected device?

Re:So big, we have to use maths

[Hurricane78]

Wrong. There always is Infinite. (The symbol is on my keyboard, but not actually displayable trough /.'s retardedly outdated ASCII(?) character set)

Sadly, zero and infinity are completely misunderstood in mathematics, for they have a temporal property to distinguish different infinites (and zeroes).

Clocks still ticking

[sunking2]

Everything is still in Beta. Don't think they can close any line items yet.

Re:Clocks still ticking

[mcgrew]

Dude, at Google everything is always in perpetual beta.

There is a huge penalty with IPV6 vs. IPV4

[laing]

Whether your routers/switches are "store and forward" or "cut over", there will be additional latency and significantly more overhead involved in routing IPV6 traffic. If the entire net were converted to IPV6 today, it would melt. Fortunately people will likely continue to use IPV4 for a long time and the IPV6 traffic will grow slowly enough that router technology will improve as necessary.

Re:There is a huge penalty with IPV6 vs. IPV4

[tukia]

there will be additional latency and significantly more overhead involved in routing IPV6 traffic

Errmm.. I think you would actually find out that with some IPv6 features like route aggregation and the checksum-less IPv6 header, things should be faster. But yes IPv6 routing without hardware capable of switching IPv6 packets will definately be slower.

If the entire net were converted to IPV6 today, it would melt.

The only reason it's going to melt is because the majority of "IPv6 support" out there uses software-based routing

Fortunately people will likely continue to use IPV4 for a long time and the IPV6 traffic will grow slowly enough that router technology will improve as necessary.

Router technology IS already here. Most hardware vendors already support IPv6 switching.

Re:There is a huge penalty with IPV6 vs. IPV4

[TheRaven64]

Care to back that up with explanations or citations? Or are we modding up all arguments by assertion these days?

Re:There is a huge penalty with IPV6 vs. IPV4

[laing]

I think that you would find, that at any data rate; say 100Gbps, it only takes 1.6ns for a complete (20 octet) IPV4 header to be digested. That's half as long as the 3.2ns it takes to digest a complete (40 octet) IPV6 header. The entire header must be digested in order to determine the route for the packet because the destination address is last. These are the theoretical best times that any hardware could achieve. That's double the one-way latency and quadruple the round trip latency. Many applications will degrade with the increased latency.

Another drawback is the added 20 bytes per IP frame. The maximum ethernet frame length is 1500 and that includes all the overhead. If the overhead consumes 20 more bytes, then your usable data-per-frame goes down by almost 3 percent. For the above reasons, IPV4 is better and should not be abandoned until necessary.

Re:There is a huge penalty with IPV6 vs. IPV4

[laing]

See my other reply in this thread.

Re:There is a huge penalty with IPV6 vs. IPV4

[Anonymous Coward]

Of course, you are assuming that new equipment will not be deployed with jumbo frames enabled. I'm not aware of any ipv6 hardware devices that do not support jumbo frames. Do you know of any? I'm can't imagine why they would not both be deployed together.

Re:There is a huge penalty with IPV6 vs. IPV4

[kasperd]

The entire header must be digested in order to determine the route for the packet because the destination address is last.

Interesting. What is the rationale behind putting the source address before the destination address? I can certainly see the point in being able to start forwarding 20 bytes earlier, but would any routers do that anyway? In many situations a router should be checking the validity of the source address before forwarding, what would you do if you already started sending the packet and then realize the source address is invalid? You cannot truncate the packet if you are using ethernet frames because the length is before the payload, so you already send the length. You could of course end the frame with an invalid checksum. That leads to another challenge, what do you actually do about packets with invalid checksum? If you forward before receiving the entire packet, any corrupt packet will be forwarded all the way to the destination, and only at that point can the link layer checksum be verified. If you cut out enough forwarding latency, it becomes impossible to discard corrupted frames. The corruption is detected at the end of the packet, and no matter how you signal that the packet is corrupted, that signal won't catch up with the head of the packet. If the packet is 1500 bytes long, and you have 40 bytes of forwarding latency at each hop it takes 38 hops for an indication of a corrupted frame to catch up with the head of the frame. Routes with more than 30 hops are rare. It will also only work between interfaces running at exactly same bit rate. If you forward from a slow interface to a fast interface, you have to wait before you start sending, otherwise you will need to send the last byte of the packet before you receive it. From a fast to a slow link you can start sending as soon as you know which outgoing interface it will go to, but the slow link is more likely to be busy, so you have to buffer anyway. (If every hop along the way forwards as soon as possible, then inserting a 10Gbit/s link somewhere on a path of 1Gbit/s links will actually increase latency rather than decrease it). All of this makes me think you have to store and forward at least on some hops along the route.

Re:There is a huge penalty with IPV6 vs. IPV4

[Anonymous Coward]

Aw, so you object to it taking longer and using more octets on the wire to do a given bulk transfer via IPvsux rather than IPv4?

The checksumless header is a false optimization that arose in the very early 1990s when the fast forwarding path for IP was often done in standard multipurpose CPUs (68000s and slightly more modern RISC chips) in a way that was strongly limited by instructions per unit time.

As early as the mid 1990s there were pipelined ASIC (and full blown specialized processor) designs that did header checksumming as a pair of pipeline stages.

Moreover, link layer checksumming is not universal and does not catch bit errors within intermediate systems.

Damage to a bit in a typical IPv6 header is unlikely to impede the delivery to very near the destination (i.e., the probability of a single bit error affecting one of the most significant bits of the destination address is low), which contributes to congestion-by-partial-delivery in the event of packet corruption. IPv4's checksum allows for an earlier drop. (Consider the case where errors are introduced in the first hop router at the source end, and a low-bandwidth bottleneck one hop before the intended destination; alternatively, consider the case where a flaky sram or programming bug introduces single bit errors distributed randomly but only within the destination address field).

You are totally on the right track, though. IPv6 was designed to solve one problem: "we are running out of class As and class Bs and we are getting bad press attention and pressure to deploy OSI" -- so SIP and PIP were smooshed together, with TUBA being ignored for political rather than practical reasons, and CATNIP declared to be "incomplete" (but really its support for TUBA and TCP directly over CLNS et al. was another political issue).

Mission accomplished: OSI went nowhere.

What the ROAD process did not consider at the time: CIDR, RIR slow start allocations, NAT, and other ways to make more efficient use of the narrow IPv4 address fields.

IPv6's approach was simply to vastly increase the number of "much bigger than class A" blocks, and Noel Chiappa and/or Mike Padlipsky and/or Mike O'Dell used to say that this was like redesigningLAPB to have 64-bit window sizes as a way of modernizing X.25.

Finally, most of the other important changes are in ancillary protocols and mechanisms which are readily adapted to IPv4 (most have been, and many originated there in the first place).

There is still demand for a modernization of the Internet Protocol, and one approach that has been learned is to retain IPv4 (and possibly IPv6) as a UNI, with arbitrary/non-uniform/no-flag-day NNIs chosen for pragmatic rather than political reasons.

Sadly, IPv6 has graduated into the role of OSI: it's the future, and governments and large organizations (MITRE then, Google now) will tell you how easy and useful it is.

Re:There is a huge penalty with IPV6 vs. IPV4

[Anonymous Coward]

Below this is an AC asking why it's harder to route IPvsux than IPv4, asserting "IPv6 is easier to route".

In the context of this discussion "route" really means "forward", rather than "propagate NLRI and construct forwarding tables", although I'll return to those at the end.

No, IPvsux is identical to route: longest matching prefix wins.

The differences are in the number of prefixes that require searching, and the average length of a prefix. The latter places lower time limits on searches, since the longer the average prefix length, the more nodes have to be traversed in a search structure (like a radix trie) on average. As the number of prefixes increase a couple factors come into play: the insertion time into the search structure (for NLRI updates, etc.) and the ability to "flatten" a radix trie into an m-way trie. In IPv4 this has been very succeessful in ways which are analogous to:

1. focus on initial 8 bits of destination address
2. perform 'n0' look up in 256-element linear table
3. change focus to second 8 bits of destination address
4. perform 'n1' lookup in 256-element linear table pointed to by n0
5. change focus to third 8 bits of destination address
6. perform 'n2' lookup in 256-element linear table pointed to by n1
7. change focus to fourth 8 bits of destination address
8. perform 'routing instruction' lookup in 256-element linear table pointed to by n2

This type of route lookup (and change) is very efficiently implemented using TCAMs, with optimization strategies closely related to hardware tuned for functional composition languages.

The much longer average prefix lengths in IPv6 require proportionally more lookups using this type of system, degrading the efficiency (or alternatively massively increasing the cost) of hardware implementations based around this sort of approach.

For instance, you could increase the bucket size from 8 bits to 16 bits or so, or you could use a much longer pipeline; either way you would also generally take a latency hit on average packets, and you would need a lot more storage for a similar number of prefixes.

Software solutions have similar problems; longest-prefix matching is expensive for long prefixes, even if you consider that the first 16 bits are essentially an AFI that doesn't need a tree lookup.

The IPv6 prefix count is small today, but it is not clear how aggregation boundaries will compare with IPv4 , other than that the "swamp" of early allocations of classful networks is still a significant fraction of all IPv4 prefixes.

Therefore, the assumption that IPvsux is easier to route rests on there remaining a very small number of IPv6 prefixes and forwarding disposition being decidable when looking only at a very few number of most-significant bits.

THESE ASSUMPTIONS ARE UNSAFE.

Returning to the other part of routing, the propagation of routing information is harder simply by virtue of the representation of the average IPv6 prefix necessarily being longer than that of the average IPv4 one, in any routing protocol at all. The construction of routing tables depends on the insertion costs into the search system described above and the frequency of insertions. There is no reason to believe that IPv6 prefixes are on average more stable than IPv4 prefixes, so the insertion frequency will depend on the overall number of prefixes. Insertion time for an average prefix is probably a constant that is probably higher for IPv6 than for IPv4, so a future slightly less noisy IPv6 routing system (because of fewer prefixes, because of the lack of "swamp") is probably the same computation burden as existing IPv4, excluding effects of hierarchical memory, etc.

However, the lack of swamp is speculative because of questions raised in considering site multihoming in IPv6, and because so little experience of large scale RIR activity has occurred, even in APRICOT (Asia-Pacific).

Re:There is a huge penalty with IPV6 vs. IPV4

[Anonymous Coward]

Destination is the last field if there are no options. Fields in IPv6 are fixed length vs variable length of IPv4 and as such can be processed in hardware.

Virtually every device can support MTU of above 1500 and it is desire they begin to do so.

Your logic is fail

Re:There is a huge penalty with IPV6 vs. IPV4

[Anonymous Coward]

The latency induced by processing a larger header will be offset by the fact the entire packet can be hardware processed. Switches are UNAFFECTED by ipv6 (switches operate at layer 2 while IP is at layer 3 remember?)

The router technology IS HERE. The demand IS HERE. Right now the only country not suffering from the lack of universal adoption of IPv6 is the US. Get over your fear of learning something new. Quit being a coward dinosaur network admin whose most in depth experience with network involves connecting a MS Server box to a net gear router and calling yourself a network god.

IPv6 is coming and those who don't adopt it are leaving with IPv4 (that means you)

Re:Yep..

[Abreu]

Some years ago, Eddie Van Halen said that guitar playing "is not as hard as brain surgery"

Sometime later, he got an offer from a brain surgeon to trade some guitar lessons for some brain surgery lessons

DO NOT WANT

[Chelloveck]

IPv6 is neither difficult nor expensive. Nor, for the most part, desired.

Re:DO NOT WANT

[shentino]

More like the people who are sitting on piles of v4's have a vested interest in keeping IP space scarce and rent producing.

Compatible? NOT

[Anonymous Coward]

Most hardware & software is NOT really IPV6 compatible, even when listed as such. Take Microsoft IIS6 on Windows Server 2003 for example. Using a specific IPv6 address for a website is not allowed, only host names. This makes it impossible to use a web server for more than 1 domain for many.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/4c7c6bce-213a-4125-bc36-2202e3b4c8c8.mspx?mfr=true
IIS7/Server 2008 fixes it.

really support ipv6?

[scientus]

except for the fact that they dont really support ipv6.

You have to "opt-in" for ipv6 service, and then they will validate that you have a ipv6 connection suitable for google, and they, at their descretion, they will send you AAAA results requested by certain dns resolvers of your network. And this isn't available for anybody but big ISPs that go through the process.

Instead if you want ipv6 google without all this hub-bub you have to mangle your dns resolver to get dns for google off an unofficial resolver that is whitelisted and does caching. (resolver2.lrz-muenchen.de works)

For a company that professes network neutrality the claiming that their whole infrastructure supports ipv6 is phooey. Also, they seem to think differently of ipv6 addresses and at least with me blocked my ipv6 address from their site claiming i was crawling them. I have never had a ipv4 address blocked like that, and i share it when a number of people.

Google should stop breaking the way the internet works and selectively giving their services out. They shouldn't be messing with the protocols and forcing ISPs to get permission to use their site.

Re:really support ipv6?

[idiotnot]

Hmm....but that resolver doesn't have an AAAA record, either (for itself...google works). :-/ I was going to add to my forwarders.

FWIW, I've noticed my netbsd mailing list messages are normally delivered v6 (hosted @ISC, I think). For many of the tunnels I've used, performance to ftp.netbsd.org is almost identical to using v4.

Re:really support ipv6?

[Tony Hoyle]

You can do some forwarding magic in bind to work around it, but I agree it sucks.

AFAIK the reason is the poor state of implementation - a lot of machines out there have ipv6 enabled but no ipv6 external routing, so their browsers will ask for an AAAA record, try to reach google over ipv6, fail, then go for the A record as a fallback - this can take several seconds.

Of course google aren't truly ipv6 *anyway* because the moment you step outside a few select pages it drops back to ipv4.. and google don't index ipv6 either, so you'll never get an ipv6 result to a search.

Re:really support ipv6?

[Tony Hoyle]

btw. ipv6 google workaround..

zone "google.com"
{
                type forward;
                forward only;
                forwarders { 2001:4ca0:0:100:0:53:2:0; };
};

Are you sure it took 4 months of solid labor?

[morgauxo]

"At 20% of 18 months, that's almost 4 months of solid labour" Is that how the 20% projects worked? Or could individual employees be involved in any number of 20% projects? If so then they could have spend considerably less than 4 months on it. Not to mention that even if they where all on it 20% of each day that means that they were working on it in short bursts. Likely working on a project this way will take longer because employees are spending a higher percent of their time just figuring out where they left off, loading programs, booting up/etc... vs time actually working.

From beneath my tinfoil hat...

[gentry]

It could be said that Google has a vested interest in IPv6; everyone has unique IP addresses. No more NAT. Further, a large percentage of these IP addresses will be generate from the MAC address of the device. Great for tracking^W targeted advertising.

Reason

[Anonymous Coward]

You have to specify why it would be harder to route IPv6 traffic than to route IPv4 traffic. Because on one level, you're wrong, and on another, you're kind of right. I'm guessing the reason you're saying that is because most routers don't have IPv6 implemented in hardware, and has to use the CPU to route IPv6 packets. But on the other hand, IPv6 is easier to route, so in the long term it'll be more effective to use IPv6.

Easy, sure...

[yourexhalekiss]

Sure, it's easy if you work for Google. :-(

ipv6ready

[tukia]

Try looking in http://www.ipv6ready.org/

OOP FTW

[jeffeb3]

This is why layering software is such a good idea.
the ipv4 software:
ip_object.GetIPHandle()

looks a lot like the ipv6 software:
ip_object.GetIPHandle()

Object Oriented Programming For The Win!

Re:Yep..

[mcostas]

Don't worry, since it's so easy, Google is donating its engineering resources to implement IPv6 for any company that wants it.

Crock

[Anonymous Coward]

Those quoted efforts are bullshit.

btw, 20% is not supposed to be in *addition* to the regular work (although it turns out that way). It's *part* of the work. one day a week to be spent on unstructured (but hopefully relevant) work.

Re:Yep..

[Anonymous Coward]

you should get some more fibre in your diet then, and drink plenty of water, too.

two basic problems

[speculatrix]

as most people have observed, most consumers are running routers which aren't even ipv6 capable, let alone even have it turned on - too little ram or rom mostly. one notable exception is Apple's Airport Extreme, and many slashdotters might be interested or worried to note that they (used to be a least) are configured to create a 6-in-4 tunnel automatically!

sensible slashdot readers with consumer grade routers will hopefully have been sensible and bought ones where they can flash a linux-base OS which will do ipv6 (e.g. the wrtg54L)

many business do use consumer gear, but there's also the issue of ipv6 support in easy to use firewall software. e.g. pfSense, a fantastic opensource firewall (based on freebsd) has no ipv6 support and it's not even scheduled (bounties welcome!) for mainline development.

many consumer broadband/asdl ISPs in the UK resell British Telecom services and ipv6 isn't possible easily.

why do people use firewalls?

[Anonymous Coward]

IP was also supposed to work in an environment where you trusted everyone else. In the real world there will be at least one firewall between you and the rest of the world so you're not really cutting down on any administrative overhead.

What the fuck do you need firewalls for? There shouldn't be any open ports facing the public 'net; anything local to the host should use 127.0.0.1 as the binding address.

Speaker claimed skype does not works behind a NAT

[Anonymous Coward]

This same guy more or less said that Skype did not behind a NAT. I was at the talk and concluded at that point the speaker was sort of clueless and more interested in promoting v6 than anything else. I will note that when I ask google people about plan to make google voice work with v6, well, there seems to be no plan for that.

It's sort of nice that google got a web server to run v6 - I note that I seem to have to use a different web URL and it's not on the normal google.com so it's more of an idle curiosity than significant deployment - but it is a long ways from getting a web server to getting a complex application with embedded addresses and multiple interfaces in use such as a typical VoIP application to work.

opt-in

[davburns]

Google does publish ipv6.google.com. And if you have classic (not ig) selected, you get an extra-fancy dancing Google logo to let you know you made it to the IPv6 version of Google.

But if you want to use their regular services, they just redirect you to plain old boring www.google.com. So it's nice that Google spent 20% of a lot of time on this, but it's not available to ordinary IPv6 connected users. I guess that's better than slashdot. (ipv6.slashdot.org has an A, but no AAAA records!)

Of course, if you want to add some entries to your ipnodes table, you can get the rest of the Google services to work for you over IPv6 and then your gmail will be extra-cool like mine.

Re:opt-in

[davburns]

Oh, and another gripe: AFAICT, googlebot does not have the ability to visit IPv6 websites. It makes me sad.

Re:Yep..

[Anonymous Coward]

You read slashdot while on the toilet? Geeze, what a loser.

I've heard this guy speak at a conference.

[Anonymous Coward]

And here is what I took away.

1) the Party Line on IPV6 is that it is easy now, they're trying to encourage people to make the switch. When you actually start digging in you find out that cisco is still charging insane licensing feeds, other vendors may not even be ready, features are missing from networking equipment that will be necessary... and let's not even start on the RA/DHCPv6 problem. This is a political message, not a solid technical one. Stop lying Google.

2) If IPv6 was so easy, why does www.google.com not have an AAAA record for the world? Oh, lots of clients will break and wont be able to get to google anymore? But I thought IPv6 was easy. Instead, you have to specifically choose to go to ipv6.google.com or tell google to switch ipv6 access on for your site by request.

Here's he problem: IPV6 isn't ready and we're about to be out of IPV4 addresses. It doesn't look like we'll be anywhere near ready to change yet, so we're getting into ugly situations like carrier grade NAT. Carrier grade NAT is going to impact the ability of companies like Google to provide applications to users. Google Maps breaks when it can't get enough connections to get map tiles. ETc.

This is a talk this guy is running around giving and its completely politically motivated. It is not motivated by technical merit.

Don't buy into the bullshit. IPv6 is going to be a huge mess for years to come.

Re:Yep..

[Techman83]

Well I know the post is funny, but in reality you don't have to implement internally straight away. All those devices that aren't capable of it can stay that way. PAT/NAT will still work even with IPv6 outside and IPv4 inside. Even the lower end of the enterprise gear is capable of it and to backup how easy it is, it takes up a very small section in the CCNA training material and our class spent about an hour on it. I understand it, it makes sense, the real barrier is fear.

New commercial

[Anonymous Coward]

So easy, a Goog can do it.

Re:Yep..

[Creepy]

Oh, no - you said the N word - you'd better go hide your family now before the IPv6 nazis take them to the death camp...

Seriously - when I mentioned I needed to find a way for IPsec packet rewriting for network address translation I was flamed by IPv6 zealots and kicked from their IRC channel. I eventually did find a solution with a hardware firewall that supported IPsec forwarding, but no thanks to them. The zealots I've talked to firmly believe all IPs should be positively identifiable and no address translation ever used (even for security and privacy reasons). Some of them also think that this will be the holy grail for finding kiddie porn vendors, spammers, and stuff like that, but have not reasonably answered how (you can spoof MAC addresses which are used in IPv6 address generation and email still has the same problems it always had - no verification and a spoof-able source).

There are advantages to IPv6 - such as faster routing, harder to spoof, built in encryption, and lots of IPs, but also some costs such as longer addresses (thus packets), no privacy, and in some respects less security because an encrypted packet can't be filtered as easily at the router.

Re:Yep..

[noppy]

Because they did this.

How to migrate to IPv6 easily

Newbs

[Anonymous Coward]

I like how these newbie windows admins like to sit and complain about everything IPv6 is not while completely ignoring what IPv4 is not. Did we all forget that we are on the verge of complete IPv4 depletion? Countries like India and China are on multi-natted architectures ALREADY because their alloted address spaces are DEPLETED.

How do you think it affects performance to have to NAT every packet that comes through your network when you're in a service provider network?

Yes there ARE things that have to be figured out with IPv6, yes there ARE apps that will have to be changed. I'm sorry if you've forgotten, you're supposed to be ENGINEERS. Wow are you really surprised when technology changes and you have to change something yourself? I'm sorry but the world cannot wait for fat lazy online university graduates just because they don't understand the technology and are too busy smoking a joint to learn it.

Get over yourselves IPv6 is coming whether you lazy GED wannabes want it or not.