...but show me a handset which does that at a price similar to unsubsidized cell phone prices. Or even simpler, show me a cell phone with BlueTooth. Not one of those that just use BlueTooth for headset connection and as a replacement for infrared, but one that actually implements the BlueTooth standard for phones, the cordless telephony profile.
Unfortunately the handset manufacturers do not sell to consumers, they sell to cellular telephony network operators which then pass the phones on to consumers cheaply. The network operators desperately need bandwidth hungry applications such as video telephony or "multimedia" messages. That is what the phone manufacturers care about providing right now. None of them would dare put anything on the market that takes bandwidth use away from the network operators.
It will happen in at most a few years though; unnatural market conditions tend to fix themselves unless conditions are truly exceptional or the government intervenes.
This is possibly the end of the browser wars, assuming AOL kills off Netscape. That is really big news to me. Your article is about yet another cloned animal. Why should I care that someone cloned a donkey?
It seems from the article that they are talking about conversations wrapped in VoIP or going through long distance services. I really cannot imagine that tapping your very own packet network such as GSM or CDMA presents a problem. It gets more challenging when customers use data calls to carry voice. Anyway, GSM is easily tappable here.
Also, cell phone companies keep track of which antennas a phone is in contact with at which signal level all the time. So if you carry a cell phone that is turned on, the phone company knows where you are.
Do not think of it as a migration. Just go dual stack. Everyone used to run dual (or even more) stack anyway, perhaps you remember IPX? NetBEUI? SNA?
As you say, push the issue (but do not call it a migration) when a new service appears where IPv6 has advantages. VoIP is one. Another is connections to internal servers at partner companies / customers / suppliers. Two-way NAT is just wrong. In 10 or 20 years you can call it a migration and celebrate by switching off the last IPv4 stack...
You place your DNS service in multiple places, of course. Should one of the providers get misrouted, no problem. I do not understand what you mean by running DNS on more IP addresses than you put in the NS and A records. Plain old DNS allows for about 13 NS records before you start hitting UDP packet limits. (More will work, but you really want to avoid DNS-over-TCP.) Still, if 13 different providers all over the world are down at the same time, I think you can safely consider the Internet dead.
Right, your DNS servers need fixed IP's. However, you should not be running your DNS servers in your own address space anyway, since they die if you lose connectivity. And multihoming is no fix for that; your AS might get misrouted somewhere. Multihoming cannot fix that.
Multihoming in IPv6 should be done simply by running two (or however many) sets of addresses in parallel. The applications should do the failover. Keep the end points smart, the network stupid.
Current routers need aggregated routes. If you start splitting routes up into/24's, they melt. So selling IP space in small pieces is definitely out. By the way, I do not see what you mean by IPv6 being totally different from IPv4. The majority of the problems I have seen with application support for IPv6 is that applications only allocate 32 bits for an IP address. Any extension of the IPv4 address space would break those applications anyway. Once you fix the applications to allow 128 bits for the address, IPv6 looks very much like IPv4. To the network administrator they are about the same too, except you do not need those pesky DHCP-servers.
You mean "Know 200 clients who need IPv6 in the next two years?"
The smallest IPv6 assignment that an ISP is allowed to give to a customer, whether it is a one-person home or a multinational corporation, is a/48. I would not call an ISP with only 200 customers "really big".
Show me a firewall capable of keeping track of 22 million NAT entries. Or a few hundred million, as would be necessary if they wanted to make a decent shot at Internet-wiring China.
I can assure you that The Great Firewall of China is stateless. And stateless firewalls can by definition not do DNAT. By the way, RFC1918 only defines 17891328 private IP addresses.
Go dual stack for most things. Migrate your VoIP fully if you can, it is one of the places where v6 has obvious advantages over v4. Legacy routers are a problem, legacy hosts are not really a problem. Just move each service over when it makes business sense; things like moving HTTP proxy traffic to IPv6 and making the proxy convert when needed. Just beware, working with IPv6 can get you addicted. Debugging IPv4 seems so tedious and troublesome after you have tried IPv4.
And before you turn that one back on me: I am already dual-stack with NAT'd IPv4 and real IPv6 addresses for the hosts. So I am not holding things back. I love autoconfiguration by the way. No configuration on the hosts at all. IPv6 is so simple and easy compared to IPv4.
Yes, it is really hard for the cell phone company to find and reassemble all the packets in your conversations. It is not like they have to do it anyway in order to be able to connect your call to the intended recipient. Or something.
That is not an excuse, it is simply the truth. *DSL needs a pair of metal wires. If you do not have that, no *DSL for you. You may have to make do with STM4. The US equivalent of STM4 is OC12, by the way.
They did not know the gram was too small. They made what they thought was a perfectly good system based on the gram. When they started to use derived units in other things like electricity, it was discovered that the derived units get inconvenient in a gram-based system. The answer is simply that today we know it would have been better if the gram had been bigger.
That is for GSM phones. "Analog" calls around here are digitized with A-law-encoding (or is it u-law? I forget which), but not compressed otherwise. With a POTS phone call you get guaranteed bandwidth, so there is no point in not sending all the time. I am sure the cheap long distance carriers use compression and signal detection though. Modem calls probably do not survive that, but who does long distance data over POTS anyway?
If it was a while since you last used gtk-gnutella, you should try it again. I am seeing about 8kbps both up and down for 10 ultras and 10 leaves. If you switch to leaf mode, you are probably down to les than 1kbps up and down.
I read the clarification, and soon thought "this guy is talking about Java and.NET, and he is on the Java side". Then I reached the bottom of the page and saw that he is employed by Sun...
At first the gram was the base unit. However, try deriving the other units from that, and you will see that units like Volt come out with inconvenient sizes for everyday measurements. So they changed to the kilogram without inventing a new name for it. This is quite unfortunate for several reasons, including the fact that everyone abbreviates it to just kilo. Also, what do you call 1000 kg? A kilokilogram? A megagram? No: A (metric) ton.
Incidentally, there will always be some units that end up with inconvenient sizes. Try going to your local electronics store and asking for a 1F capacitor.
It is worse than you think. Some 650's use one chipset, some use another. One chipset works in Linux, one does not. If you buy one for Linux, you are effectively buying a lottery ticket.
The low end is catching up. Try googling for I2O, for one thing. Interrupts are not a big problem anymore, peripherals switch to polling when under load. Remember, CPU power is cheap at the low end. Who cares if one or two processors do very little except managing the I/O when there are 30 more of them free to do actual work?
Mainframes sell because of the complete environment, with partitioning, hardware resilience, all that good stuff. There is nothing like creating a new virtual machine with a copy of the system, testing a new release, and then switching over. I am green with envy.
Oh and if someone needs loving care for their mainframe, I am certainly for hire... No experience with mainframes yet, but I can learn.
Slashdot Mirror
Unfortunately the handset manufacturers do not sell to consumers, they sell to cellular telephony network operators which then pass the phones on to consumers cheaply. The network operators desperately need bandwidth hungry applications such as video telephony or "multimedia" messages. That is what the phone manufacturers care about providing right now. None of them would dare put anything on the market that takes bandwidth use away from the network operators.
It will happen in at most a few years though; unnatural market conditions tend to fix themselves unless conditions are truly exceptional or the government intervenes.
Please hurry and download the release candidate so the rest of us can have the final 1.4 tomorrow. Thank you for your cooperation.
This is possibly the end of the browser wars, assuming AOL kills off Netscape. That is really big news to me. Your article is about yet another cloned animal. Why should I care that someone cloned a donkey?
Also, cell phone companies keep track of which antennas a phone is in contact with at which signal level all the time. So if you carry a cell phone that is turned on, the phone company knows where you are.
As you say, push the issue (but do not call it a migration) when a new service appears where IPv6 has advantages. VoIP is one. Another is connections to internal servers at partner companies / customers / suppliers. Two-way NAT is just wrong. In 10 or 20 years you can call it a migration and celebrate by switching off the last IPv4 stack...
You place your DNS service in multiple places, of course. Should one of the providers get misrouted, no problem. I do not understand what you mean by running DNS on more IP addresses than you put in the NS and A records. Plain old DNS allows for about 13 NS records before you start hitting UDP packet limits. (More will work, but you really want to avoid DNS-over-TCP.) Still, if 13 different providers all over the world are down at the same time, I think you can safely consider the Internet dead.
Multihoming in IPv6 should be done simply by running two (or however many) sets of addresses in parallel. The applications should do the failover. Keep the end points smart, the network stupid.
Current routers need aggregated routes. If you start splitting routes up into /24's, they melt. So selling IP space in small pieces is definitely out. By the way, I do not see what you mean by IPv6 being totally different from IPv4. The majority of the problems I have seen with application support for IPv6 is that applications only allocate 32 bits for an IP address. Any extension of the IPv4 address space would break those applications anyway. Once you fix the applications to allow 128 bits for the address, IPv6 looks very much like IPv4. To the network administrator they are about the same too, except you do not need those pesky DHCP-servers.
The smallest IPv6 assignment that an ISP is allowed to give to a customer, whether it is a one-person home or a multinational corporation, is a /48. I would not call an ISP with only 200 customers "really big".
I can assure you that The Great Firewall of China is stateless. And stateless firewalls can by definition not do DNAT. By the way, RFC1918 only defines 17891328 private IP addresses.
Go dual stack for most things. Migrate your VoIP fully if you can, it is one of the places where v6 has obvious advantages over v4. Legacy routers are a problem, legacy hosts are not really a problem. Just move each service over when it makes business sense; things like moving HTTP proxy traffic to IPv6 and making the proxy convert when needed. Just beware, working with IPv6 can get you addicted. Debugging IPv4 seems so tedious and troublesome after you have tried IPv4.
Why do you want your addresses to be portable? Renumbering IPv6 is trivial. It is not like I remember the addresses anyway.
Who will HP buy next after Compaq?
Apple
HP has 15.*, Compaq has 16.* (from DEC), Apple has 17.*...
(That will be the end though, 14 is reserved by IANA and 18 is MIT.)
And before you turn that one back on me: I am already dual-stack with NAT'd IPv4 and real IPv6 addresses for the hosts. So I am not holding things back. I love autoconfiguration by the way. No configuration on the hosts at all. IPv6 is so simple and easy compared to IPv4.
Yes, it is really hard for the cell phone company to find and reassemble all the packets in your conversations. It is not like they have to do it anyway in order to be able to connect your call to the intended recipient. Or something.
That is not an excuse, it is simply the truth. *DSL needs a pair of metal wires. If you do not have that, no *DSL for you. You may have to make do with STM4. The US equivalent of STM4 is OC12, by the way.
They did not know the gram was too small. They made what they thought was a perfectly good system based on the gram. When they started to use derived units in other things like electricity, it was discovered that the derived units get inconvenient in a gram-based system. The answer is simply that today we know it would have been better if the gram had been bigger.
Because the gram is a widespread unit already. You are a few hundred years late with that suggestion.
That is for GSM phones. "Analog" calls around here are digitized with A-law-encoding (or is it u-law? I forget which), but not compressed otherwise. With a POTS phone call you get guaranteed bandwidth, so there is no point in not sending all the time. I am sure the cheap long distance carriers use compression and signal detection though. Modem calls probably do not survive that, but who does long distance data over POTS anyway?
"Prefer compressed" is great, by the way.
I read the clarification, and soon thought "this guy is talking about Java and .NET, and he is on the Java side". Then I reached the bottom of the page and saw that he is employed by Sun...
Wow.
Incidentally, there will always be some units that end up with inconvenient sizes. Try going to your local electronics store and asking for a 1F capacitor.
It is worse than you think. Some 650's use one chipset, some use another. One chipset works in Linux, one does not. If you buy one for Linux, you are effectively buying a lottery ticket.
Mainframes sell because of the complete environment, with partitioning, hardware resilience, all that good stuff. There is nothing like creating a new virtual machine with a copy of the system, testing a new release, and then switching over. I am green with envy.
Oh and if someone needs loving care for their mainframe, I am certainly for hire... No experience with mainframes yet, but I can learn.