Google Deploys IPv6 For Internal Network
itwbennett writes "Google is four years into a project to roll out IPv6 to its entire internal employee network. At the Usenix Large Installation System Administration (LISA) conference in Boston last week, Google network engineer Irena Nikolova shared some lessons others can learn from Google's experience. For example: It requires a lot of work with vendors to get them to fix buggy and still-unfinished code. 'We should not expect something to work just because it is declared supported,' the paper accompanying the presentation concluded."
"'We should not expect something to work just because it is declared supported,' the paper accompanying the presentation concluded."
I think that if something is declared "supported", it is perfectly reasonable to expect it to work. If it turns out it doesn't work, I think the problem is more that the vendor hasn't done as good a job as they should have than that your expectations were too high.
Please correct me if I got my facts wrong.
assignment of smaller blocks may have extended the life of IPv4 addresses however, there are physically not enough addresses for the devices we currently have. While, there may be enough at the moment, there wont be soon.
What is IPv4; 4.3 billion addresses. There are over 6 billion people on earth and many people in the western world have numerous devices. My household of 2 has 8 devices that are nearly always online. (Computers, Phones, Top-set Boxes, printers, etc....) This number does not take into account either one of our work sites which probably add another 1-2 addresses to that number.
And no, NAT is not a solution.
Something no one would need if proper assignment of IP ranges had been done.
No point asking what you mean, since you evidently speak from ignorance. Even with optimal assignment of IPv4 addresses, it would only delay the inevitable shortfall. Sooner or later, the number of addressable end-points on the internet would exceed 4 billion. NAT is an unfortunate workaround to delay the effects of the shortfall; it should be a freely-chosen option, not an enforced requirement.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
Right, if decades ago the inventors of the internet had realized that it would scale from 10s of users to billions. I'd say the address space length that they used still makes it outrageously overengineered for the time, and we're lucky they had the vision that they did. To criticize them is preposterous.
Uhm, it's obvious something dropped <sup> tags. Just like, for example, Slashdot does.
Try this: 2<sup>80</sup> -> 280. Not the writer's fault, the blame lies on editors who didn't notice their software mutilates basic harmless tags.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
2^32 - 2^24 - 2^16 - 2^20 - 2^16 - 2^28 = 4008574976. That's if you put them all on one giant flat network from hell, and so didn't use any for network or broadcast addresses. Yes, 2^16 in there twice - don't forget APIPA. The 2^28 is reserved for multicast.
I'd say the address space length that they used still makes it outrageously overengineered for the time, and we're lucky they had the vision that they did.
Not really. Don't forget there is a HUGE difference between the old classfull and VLSM/CIDR/classless numbering. That gain is the whole point of spending all that effort implementing netmasks. There really were not that many possible classfull lans compared to the number of minicomputer owning businesses in the world, etc.
For the post-92ish noobs, a really simple one line explanation is the netmask used to be stored inside the address itself, so for example if the first octet was 0 to 127, that meant that LAN had to be a (presumably giant bridged) /8, first octet 128-191 meant the netmask had to be a /16, not defaulted or was a pretty good guess, but operationally "had to be".
The early years of VLSM were pretty entertaining, old timers lecturing us how a LAN addressing scheme like 1.2.3.0/24 was "impossible" and so forth.
Without VLSM we would have to have done the ipv6 conversion years before the dotcom boom, rather than a decade or so after. Not entirely sure if we'd all be better off now, or not.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
And while the current versions of most OSes support IPv6, they do not do so by default.
What are those OSes? Its been a long time since I turned on ipv6 at home. As I recall I had to do little other than turn it on. There is a difference between "activate" which is kind of like setting the sound mixer output to a comfortable level no big deal, vs searching on the internet to install 3rd party drivers and/or recompiling kernels.
Windows 7 actually defaults to it being turned on, but will generally not do anything with it if it doesn't get an IPV6 DHCP address. But some MS technology (like the Win7 HomeGroup support, and DirectAccess) work via IPV6. Odds are there are a TON of people using IPV6 on their home network and just don't know it.
Just think how long it would take companies without access to virtually unlimited funds and brain power. It's no wonder everyone is reluctant to make the move.
Oh man, what I would have given to be there for that conversation.
"How many addresses do you figure we need?"
"Couple billion I guess."
"But what if we need more?"
"Dude, okay, let's just say one per person. 4 and a half billion or so. Now everyone on the world can have one."
"But what if, you know, there ends up being a few more people than that in the future?"
"Jesus Christ man, it's not like 3 billion extra people are gonna pop up out of nowhere in the next 30 years!"
Random Thoughts From A Diseased Mind (Not For Dummies)
Because the hardware that can handle large amounts of small packets fast when you install your own software ('firmware'), does not exist AFAIK. Atleast not the type which will also be supported by (multiple) vendors (no1 wants to be stuck on, locked into, one vendor). designing not-massproduced ASICS isn't cheap. It would be like Google designing their own CPU's for their servers.
The closest things are:
- NetFPGA (some people at Google worked on that project I believe) / LibreRouter - which use FPGA's to handle packets, you tell it how to do that.
- projects like Netmap, handle packets in userspace so you don't have to push packets through the kernel on normal PC-hardware, making it faster: http://www.youtube.com/watch?v=SPtoXNW9yEQ
The best chance currently to be useful in 'doing your own thing' is probalby:
- OpenFlow, which basically is an API standard which multiple vendors would support to describe what the hardware in a switch should be doing, a programming language almost. Some demo's:
http://www.youtube.com/user/stanfordopenflow
Which can allow for lots of tricks, like 'software defined networking'
New things are always on the horizon
Remember the mini-computer didn't even exists then.
So a computer was a large machine which took up a room.
And it was just an experiment, the experiment never ended.
If you want to know more about what the original creators thought, you should look up talks by Vint Cerf:
http://www.youtube.com/results?search_query=vint+cerf+ipv4+ipv6+depletion
For example this video:
http://www.youtube.com/watch?v=LcXCieD5YKE
New things are always on the horizon
you see, the good thing is not the NAT, but the firewall dropping packets from outside, again. As always, the people say the security comes from NAT, and really mean the requirement of having a firewall which drops packets coming in, because there is no mapping to which internal ip they should be routed.
Decades ago, the engineers did in fact consider 128 bit addresses, but in the end they went with 32 specifically because v4 was not considered a "production" version. There's a link on the wikipedia page for ipv6 to a video with vint cerf explaining exactly that.
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
That's not how IPv4.1 works. Check the facts.
Do you care about the security of your wireless mouse?
IPv6 is very popular in Asia, and you have a large number of Eastern languages sites that are only reachable on IPv6 (some only have IPv4 for western visitors if their content applies).
And on ISPs. Cox and Time Warner (Road Runner) started running consumer IPv6 pilots this year, and I wouldn't be surprised if other ISPs also started.
The limiting factor is going to be the home routers. But as more ISPs begin offering the option (maybe bundled with a "higher performance tier" that will tie in with net neutrality), we'll likely see home routers advertising IPv6 support as if it was a new type of faster wireless. Albeit, it might take years.
Of course sometimes its still necessary, avoiding that just isn't as flexible.
SIP/H323 are a good example as the media has to be sent in a separate RTP connection. If it's not immediately obvious why that's the case RTP has to be sent as UDP to avoid latency/loss making a call unusable which TCP would. SIP can use TCP and H323 always does, so you can't send the media in the same connection.
Plus a lot of telecom environments don't have the same server handling the media as the signalling. One such use case is sometimes you get the phones to bypass the server and talk directly. That means less latency and less bandwidth used at the server, but it is only possible where end-to-end connectivity between the phones is is possible and NAT almost always breaks that.
The easy solution is to replace all your hardware with Apple products. It's what Steve would have wanted
NAT killed one of the basic principles of the internet and you're trying to make it look like a good thing.
I thought there was an announcement that the IPv4 address space is now totally exhausted. Or at least there are no new blocks to be assigned. The tunnel broker, Hurricane Electric indicates that IPv4 is exahusted.
The announcement - http://www.nro.net/news/ipv4-free-pool-depleted - was made when IANA, the central authority, ran out of addresses to give to the five regional internet registries. These regional registries will run out at different speeds. Geoff Huston's graph is very useful to see how fast this will happen - http://www.potaroo.net/tools/ipv4/plotend.png