Overly clever client-server application programmers using the client private IP address as a unique client identifier, formatting them on the wire with inet_ntop, and the server failing when it can't parse them. Stupidity like that.
You're probably going to be surprised when you find out how many web applications fail comically, when their clients come from IPv6-only hosts through a NAT64+DNS64 gateway, because stupid web coders think clients have to have an IPv4 address to communicate with their server.
It's a non-trivial number. A lot of them are proprietary enterprise applications. My employers have a raft of them. People are beginning to notice that IPv6 transition isn't something can ignore for much longer.
There is a code-signing facility in Mac OS X.
It's optional for 3rd-party applications, but many of the system components make use of it. If people want to run Samba on Mac OS X, there is this thing called MacPorts where you can find its port of Samba, plus lots and lots and lots of other GPLv3 software, and none of it requires an Apple code signature to run.
That may or may not be what you want. Choose wisely.
>
Apple did that when they decided not to accept sexually explicit material.
Yes, and after I questioned those "people" (there was exactly one of them) about where they got their information and the accuracy of it, they posted a correction and an apology. Did you see it?
p.s. I wouldn't expect a press release from Apple about this. I mean, really... think about that for a moment. Seriously?
This is absolutely not true. In fact, the only currently shipping product that doesn't support both DHCPv6 and RDNSS for name server configuration is Mac OS X 10.6. Everything else Apple ships with an IP stack in it, i.e. Apple TV, iPhone, iPad, iPod Touch, AirPort and Time Capsule, all use both DHCPv6 and RDNSS to obtain their DNS configuration.
Members of Apple Developer Connection with access to the Mac OS X 10.7 Developer Preview can look for themselves to see if the pattern continues. (I'm not going to comment about features of technically unreleased forthcoming products.)
At times like this, I often turn to the RFC series, which is a trove of useless answers to questions like this. From "Terminology for Describing Internet Connectivity" (RFC 4084):
* Client connectivity only, without a public address.
This service provides access to the Internet without support for
servers or most peer-to-peer functions. The IP address assigned
to the customer is dynamic and is characteristically assigned from
non-public address space. Servers and peer-to-peer functions are
generally not supported by the network address translation (NAT)
systems that are required by the use of private addresses. (The
more precise categorization of types of NATs given in [2] are
somewhat orthogonal to this document, but they may be provided as
additional terms, as described in Section 4.)Filtering Web proxies are common with this type of service, and
the provider SHOULD indicate whether or not one is present.
I still think you're missing the point.
If Cisco sells you a box that has feature set A and books every cent you pay for it as revenue at the time of sale, then later gives you an update that extends feature set A with feature set B, which has a non-zero marketable value and for which they are not charging you any money, then they are not being truthful in the reporting of their revenues to investors. As a shareholder, I might prefer they didn't lie to me about how much money they are really making each quarter by hiding the costs of delivering features to customers in future quarters and not reporting them to me.
The key question is whether they recognize the revenue they received in exchange for delivering both feature sets A and B at the time of your purchase, when you received only feature set A and not B. Unless they deferred recognition of those revenues until later, that means the revenues associated with the value of feature set B were reported to investors before they were actually produced and delivered. This may seem trivial at the level of ones and twos, but when it goes on at the level of millions of units, it starts to make investors pay attention.
Now, if Cisco plans to sell you the firmware upgrade that adds feature set B, then they will be able to claim you're paying market value at the time of delivery, and their books will be clean. But if they give it away for free when it's clearly a new feature of non-zero market value but the market isn't getting a chance to mark the value appropriately, then that suggests an accounting irregularity and grounds for an investor lawsuit.
One assumes they deferred the revenue or they're preparing to amend their reports after the fact and hope none of their investors sues over it.
I think you missed the point. If Cisco is delivering new features in free-as-in-beer firmware updates to those older routers, then those people paid for those features when they bought the product initially while Cisco hasn't actually delivered them yet.
Some of us remember the Enron and Worldcom financial/accounting scandals where that was one of the ways they hid the salami: booking the revenue now for features you don't actually deliver until N years from now. It was called fraud back then... wonder what the kids are calling it these days.
You mean, people paid money to Cisco for features they still haven't gotten yet? Did Cisco book that revenue yet, or did they defer booking it until the feature will actually be delivered? Inquiring accountants who remember the Enron scandal want to know!
> IPv6 has no upgrade path from IPv4...
More accurately, IPv4 has no clean upgrade to path to anything with more address space. The flag-day was baked into the cake when we had the first round of panic attacks about address depletion, back when we deployed ubiquitous IPv4/NAT for address amplification purposes and broke the IPv4 option mechanism forever.
> Does the existing 'net suddenly start to rot away or what?
Yeah, the IPv4 'net pretty much rots away as more hosts are attached behind large-scale service provider NAT444 and NAT64 gateways that impose latency, bandwidth and reliability limits on the IPv4 ghetto.
Mod this up. I've seen a lot of screwy analogies, but this one is first class. (Of course, there is the minor problem that half the world's economists seem to have completely forgotten everything the world has ever learned about macro. "Perhaps macroeconomics should be banned." —J. Bradford DeLong.)
"Or am I completely missing something that would have made this impossible?"
What you're missing is that IPv4 isn't forward compatible with any possible expansion of the address space.
Apple already did. It's called Back To My Mac (BTMM), it was introduced in Mac OS X 10.5. Application services available over BTMM must be IPv6-enabled or they don't work.
With your bare hands?!?
