> and I believe similar functionality is also in Safari.

Wrong.

Um... because we'd all rather write 2001:db8:0:a::101 instead of 32.1.13.184.0.0.0.10.0.0.0.0.0.0.1.1? Especially since, for anyone with much experience in IPv6 at all, we can look at the former and see the special documentation prefix 2001:db8::/32 at a glance, then see that the subnet identifier is "0:a" and the host identifier is "101" and we're good. That dot delimited version doesn't look so good next to that, does it?

You should expect that avoiding IPv6 will mean paying extra in the not too distant future.

If your computer only knows how to send packets to 4-octet IP addresses, how does it communicate with other computers that have the new longer addresses you're proposing?

> The last thing I want is every device in my home having a globally addressable IP address.

But you're totally okay with them having globally routed private realm IPv4 addresses. Good to know.

Hell, your wireless provider has almost certainly set up a special backdoor for them to get this information about anyone they want without even having to write a letter or speak to a human being. It's a pain in the ass to read and respond to all those letters. It's a pain in the ass to have to write them. Everyone is happier when the cops just log into the LE portal and take whatever data they want.

Everyone loves cops, and everybody wants to help them fight crime and stuff! You love the cops, don't you? Of course, you do. Now, shut up and go back to whining about the fact your location services cache got backed up in the clear to your personal computer.

Which would be relevant if the UDID of the device were being sent to the global database. Gee, I wonder what the letter says about that. I wonder what identifiers competing devices with location services send. I wonder if anybody actually cares about trivial details like that.

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.

> ...If Apple rejects this app, they'll be attacked for infringing on free speech, supporting a particular political agenda...

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.