So, the good news for you must be that with the Internet filling up, you won't have to keep growing so fast and you can stop buying new equipment every two years.
On the other hand, now that the Internet is almost full, the capacity should stop growing altogether pretty soon and all that equipment they're buying this year and the next ought to suffice until the end of time.
That's what they all said when it was time to ditch IPX and Appletalk and get connected to this thing called the Internet. Now, the Internet is almost full, so if your business plans are predicated on the idea that the number of Internet users will continue to grow at the current rate for the next ten years, then they probably need revising.
I actually thought the troll in question was so nearly pitch perfect that it had to be a parody. Look on the bright side. Slashdot has seen its first IPv6 parody troll! Oh, frabjous day!
You've already had ten years to work on the IPv6 transition, and you're still going to need several more before you will be ready for it? You deserve to have your business crushed by your competitors who are IPv6 ready today.
I suppose now would be a good time to point out that RFC 5681 is the most current specification of the standard for TCP congestion control. Would it be asking too much for people to stay current on the RFC series before they start cracking off about standards compliance?
Let this be a lesson to everyone: there is no such thing as a "white hat" hacker. If you're a "security researcher" and you're not on the payroll of the U.S. Treasury, then the United States of America suspects you're much more likely to be an enemy combatant than the average person in the general population. And even if you are on the payroll, your employment can be terminated at any time without notice or cause.
There is no such thing as a white hat hacker. It's complete bullshit.
We told you folks who dislike intrusive state surveillance regimes that breaking IPsec with NAT would come back to haunt you. Did you listen? No. This is what your carelessness bought for us all, so you can suck it up and enjoy the loving caresses of police protection like the rest of us.
Iljitsch still hasn't reviewed the source code either, it seems. The issue has nothing to do with CNAME records, and that's a claim that could be tested by anyone willing to review the source code.
It's really not obligatory. Really. Besides, the article is more than a little out of date. Maybe I should write an update, because I mean, yes, IPv6 is a mess. It is. But DJB's article is talking about the state of the mess a long damned time ago. It's a whole new mess now.
The distinction between command line and Aqua is irrelevant. The important distinction is whether the application is using its own embedded DNS resolver or using the system libinfo framework.
If you can reproduce the problem with Mac OS X 10.6.5, then please file a new report here.
No, it has nothing to do with the CNAME record, and this is a fact that anyone with the ability and the time to read the Darwin source code can readily verify. I don't know who TheRaven64 is, but he/she is correct. Use the source, Luke. It's not like there are any deep secrets in there.
I was at the CableLabs Summer Conference last year, where the representative from Cisco said their plan was to have native dual-stack IPv6 support across the entire Linksys product line by summer next year. I heard the same thing from a different Cisco person at NANOG 49 in San Francisco earlier this year. We'll see if they achieve that schedule, but that's was what they were saying off the record. [Disclosure: I work for another equipment maker in the same category.]
A lot of people don't realize that going from unstructured IPv4 addresses to structured IPv6 addresses means that the 128-bit fixed address size places an upper bound on the aggregate size of all the structured subfields encoded in an address. For an example of how this pressure is already beginning to arise, have a look at how ARIN and NANOG are reacting to the 6RD proposal.
This would mean updates to all hosts and all NAT devices...
And that's why what you're talking about wouldn't have been any better than IPv6. It requires updates to almost every unmanaged residential host and gateway before anybody would be able to rely on it, which is the main problem with IPv6. Only, your proposal doesn't fix any of the other problems in IPv4 in the process. it just adds address space, and in that sense, isn't really better or different than Realm-specific IP [RFC 3103], which ended in precisely the same ignominious failure that your idea would have met. QED.
I assert that the migration would already have happened (and seamlessly) if we had just extended the address space and left everything else the way it was.
That "solution" would have still presented as "ships in the night" and uptake would have been resisted for all the reasons that uptake of IPv6 has been resisted: no forward or backward compatibility. The fixed address size in IPv4 is the cause of the compatibility problems, but it's very badly exacerbated by the ubiquity of network address translators.
At some point, the fixed address size in IPv6 may turn out to cause similar related problems, but we should be in a better position to avoid them as long as we don't succumb to the siren call of adding back network address translation on IPv6.
Probably around the same time we stop pretending that a toothless regulatory agency staffed via a revolving door to the regulated industry is functionally equivalent to a Stalinist command and control economy.
or perhaps, demanding higher prices from those customers who refuse to be NATed...or perhaps just refusing to assign public addresses to anybody. "Don't like it? Tough. Call your congressman."
Slashdot Mirror
So, the good news for you must be that with the Internet filling up, you won't have to keep growing so fast and you can stop buying new equipment every two years.
On the other hand, now that the Internet is almost full, the capacity should stop growing altogether pretty soon and all that equipment they're buying this year and the next ought to suffice until the end of time.
That's what they all said when it was time to ditch IPX and Appletalk and get connected to this thing called the Internet. Now, the Internet is almost full, so if your business plans are predicated on the idea that the number of Internet users will continue to grow at the current rate for the next ten years, then they probably need revising.
I actually thought the troll in question was so nearly pitch perfect that it had to be a parody. Look on the bright side. Slashdot has seen its first IPv6 parody troll! Oh, frabjous day!
You've already had ten years to work on the IPv6 transition, and you're still going to need several more before you will be ready for it? You deserve to have your business crushed by your competitors who are IPv6 ready today.
I suppose now would be a good time to point out that RFC 5681 is the most current specification of the standard for TCP congestion control. Would it be asking too much for people to stay current on the RFC series before they start cracking off about standards compliance?
Let this be a lesson to everyone: there is no such thing as a "white hat" hacker. If you're a "security researcher" and you're not on the payroll of the U.S. Treasury, then the United States of America suspects you're much more likely to be an enemy combatant than the average person in the general population. And even if you are on the payroll, your employment can be terminated at any time without notice or cause.
There is no such thing as a white hat hacker. It's complete bullshit.
We told you folks who dislike intrusive state surveillance regimes that breaking IPsec with NAT would come back to haunt you. Did you listen? No. This is what your carelessness bought for us all, so you can suck it up and enjoy the loving caresses of police protection like the rest of us.
Iljitsch still hasn't reviewed the source code either, it seems. The issue has nothing to do with CNAME records, and that's a claim that could be tested by anyone willing to review the source code.
A better example would be sourceforge.com.
It's really not obligatory. Really. Besides, the article is more than a little out of date. Maybe I should write an update, because I mean, yes, IPv6 is a mess. It is. But DJB's article is talking about the state of the mess a long damned time ago. It's a whole new mess now.
The distinction between command line and Aqua is irrelevant. The important distinction is whether the application is using its own embedded DNS resolver or using the system libinfo framework.
If you can reproduce the problem with Mac OS X 10.6.5, then please file a new report here.
No, it has nothing to do with the CNAME record, and this is a fact that anyone with the ability and the time to read the Darwin source code can readily verify. I don't know who TheRaven64 is, but he/she is correct. Use the source, Luke. It's not like there are any deep secrets in there.
I was at the CableLabs Summer Conference last year, where the representative from Cisco said their plan was to have native dual-stack IPv6 support across the entire Linksys product line by summer next year. I heard the same thing from a different Cisco person at NANOG 49 in San Francisco earlier this year. We'll see if they achieve that schedule, but that's was what they were saying off the record. [Disclosure: I work for another equipment maker in the same category.]
Doesn't adoption of IPv6 remove one of the more effective layers of security we have today, the obfuscation layer, being hidden behind the router?"
Please read Local Network Protection for IPv6 [RFC 4864].
You've obviously never tried to build a router in hardware.
Running code will get you halfway there, but if you're hoping to set a protocol standard with it, you'll need to get a lot better at politics.
I agree, and further assert that it is not too late to go back and do that.
I await the submission of your Internet Draft with bated breath.
A lot of people don't realize that going from unstructured IPv4 addresses to structured IPv6 addresses means that the 128-bit fixed address size places an upper bound on the aggregate size of all the structured subfields encoded in an address. For an example of how this pressure is already beginning to arise, have a look at how ARIN and NANOG are reacting to the 6RD proposal.
This would mean updates to all hosts and all NAT devices...
And that's why what you're talking about wouldn't have been any better than IPv6. It requires updates to almost every unmanaged residential host and gateway before anybody would be able to rely on it, which is the main problem with IPv6. Only, your proposal doesn't fix any of the other problems in IPv4 in the process. it just adds address space, and in that sense, isn't really better or different than Realm-specific IP [RFC 3103], which ended in precisely the same ignominious failure that your idea would have met. QED.
I hear he's really fat.
I assert that the migration would already have happened (and seamlessly) if we had just extended the address space and left everything else the way it was.
That "solution" would have still presented as "ships in the night" and uptake would have been resisted for all the reasons that uptake of IPv6 has been resisted: no forward or backward compatibility. The fixed address size in IPv4 is the cause of the compatibility problems, but it's very badly exacerbated by the ubiquity of network address translators.
At some point, the fixed address size in IPv6 may turn out to cause similar related problems, but we should be in a better position to avoid them as long as we don't succumb to the siren call of adding back network address translation on IPv6.
If I had a dollar for every time I've been proven wrong after saying exactly that, it would make my preparations for retirement a lot easier.
Probably around the same time we stop pretending that a toothless regulatory agency staffed via a revolving door to the regulated industry is functionally equivalent to a Stalinist command and control economy.
or perhaps, demanding higher prices from those customers who refuse to be NATed ...or perhaps just refusing to assign public addresses to anybody. "Don't like it? Tough. Call your congressman."