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.
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!
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.)
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.
You should review I-D.ietf-behave-v6v4-framework. It sounds like you're talking about either scenario 4 "an IPv4 network to the IPv6 Internet" or scenario 6 "an IPv4 network to an IPv6 network", but I can't actually tell from your question. It matters because the latter is sorta/kinda doable with SIIT, but the former is just a bag of hurt, i.e. requires NAT-PT, which is deprecated for all the reasons listed in RFC 4966. Wikipedia has a decent page on transition mechanisms with some links to software you could try.
Owners? There are owners? When did this happen? Because I'm pretty sure that nobody is accounting their IP address allocations in their asset books. Do we have to pay taxes on their appreciation as capital gains? Windfall? Inquiring minds want to know.
Also, as for the argument about data center applications of NAT, I have another point to make:
There is a difference between A) using NAT because it's one of several available solutions to a problem with no perfect solution, and B) using NAT because it's a requirement of the network architecture.
Your data center application is an example of the latter, but my entry into this thread was on a topic that was an example of the former. We can move the goalposts, but let's be honest about why we're doing it, eh?
I totally feel your pain, but there really isn't cause to panic about privacy addresses and stateless autoconfig... if you don't want your salesmen to be using them, then set A=0 in prefix advertisements and set the DHCP server to hand out temporaries instead.
No, you're not going to be needing a NAT with IPv6 for normal mobile, residential and small-office usage scenarios.
I grow weary of explaining that A) NAT is not a firewall, B) your private addresses are every bit as routable as your public address when you're using a NAT gateway, and C) that just because you don't have a NAT in your cheap consumer grade IPv6 home router, it doesn't mean you won't have the cheap "simple security" functions that commonly associated with NAT gateways.
Instead, I will point you at the forthcoming RFC 6092 and its predecessor RFC 4864 and hope for the best.
p.s. Yes, you can get IPv4/NAT home routers that also route IPv6. I could recommend several alternatives, but that would be rude of me.
p.p.s. You may assume that the author of RFC 6092 knows full well that Joe User doesn't have a clue. That's the idea.
Prepare to be amazed by a sudden wave of IPv6-only mobile hosts behind broken and unreliable subscriber aggregating NAT64+DNS64 gateways that will start coming online just about the time your RIR's pool runs dry, which you will be very lucky indeed if it takes as long as five years to happen.
Or don't prepare. That way you can look brilliant when your boss says, "How is it possible you didn't see this coming and prepare for it?"
I talk with people from the majority of large carriers at IETF meetings fairly on a regular basis. I've yet to meet one who says different. As far as I know, no one in the operational community is complaining about IETF documents that recommend prefix delegation as the best current practice for commercial internet service. The 3GPP standards all assume prefix delegation to IPv6-capable mobile handsets.
Of course, if you have evidence to the contrary, I'd love to see it.
I was gonna explain all this here, but instead, I'll just drop this link. Suffice to say that there are a lot of contributors to "IPv6 brokenness" and older Mac OS X [especially pre-10.6.5] behaviors are only one of several ways that Internet users will have problems on World IPv6 Day.
This is bullshit. Every single ISP I know that offers IPv6 service today delegates a prefix. All the ones I know that are preparing commercial IPv6 services will be delegating prefixes. Even the tethering you're going to get from your IPv6-capable mobile phone will delegate a/64 prefix. Most residential providers will delegate at least a/56 and the ones run by SMART PEOPLE will delegate a/48 to each subscriber.
There is no need for residential. mobile and small-office subscribers to use NAT for IPv6.
The exception: dual-stack hosts, e.g. Mac OS X, Windows 7, iOS 4, Linux, FreeBSD, etc., on home networks with dual-stack gateways which comply with I-D.ietf-v6ops-cpe-router by advertising a unique-local IPv6 prefix even when there is no globally routable prefix available from their service provider.
Some of the newer, popular routers in the field are doing this today. Yours might be doing it right now, and you may not actually know it until World IPv6 Day arrives, when your access to Facebook, Yahoo! and Google will either be impaired or denied outright, depending on various geeky technical factors. The point of doing the World IPv6 Day exercise is to find out just how bad this problem is going to be.
On top of that, we have an excellent way to keep your teen-age daughter from running up the home phone bill with 900 services: an unlisted number! She won't be able to make trouble if she can only make outgoing calls.
If you don't want any host outside your house to communicate with your NAS box, then giving at a private address behind a NAT is the wrong thing to do. Every private address behind a NAT gateway is routable to exterior domains. If you assign a globally routable address to your NAS box, even a private one from RFC 1918, then you need a firewall to prevent it from communicating with hosts in exterior domains. (No, your cheap commodity NAT gateway is not a firewall.)
With IPv6, you can assign your NAS box a non-routable address because you don't need a NAT gateway as your home router.
Which is why many of the big content providers are doing engineering trials of dual-stack IPv4/IPv6 service, i.e. they want to be able to reach those IPv6-only subscribers. The content providers who aren't doing that will be replaced by native and local content providers who will.
Slashdot Mirror
> ...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):
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.
You should review I-D.ietf-behave-v6v4-framework. It sounds like you're talking about either scenario 4 "an IPv4 network to the IPv6 Internet" or scenario 6 "an IPv4 network to an IPv6 network", but I can't actually tell from your question. It matters because the latter is sorta/kinda doable with SIIT, but the former is just a bag of hurt, i.e. requires NAT-PT, which is deprecated for all the reasons listed in RFC 4966. Wikipedia has a decent page on transition mechanisms with some links to software you could try.
Owners? There are owners? When did this happen? Because I'm pretty sure that nobody is accounting their IP address allocations in their asset books. Do we have to pay taxes on their appreciation as capital gains? Windfall? Inquiring minds want to know.
Also, as for the argument about data center applications of NAT, I have another point to make:
There is a difference between A) using NAT because it's one of several available solutions to a problem with no perfect solution, and B) using NAT because it's a requirement of the network architecture.
Your data center application is an example of the latter, but my entry into this thread was on a topic that was an example of the former. We can move the goalposts, but let's be honest about why we're doing it, eh?
I totally feel your pain, but there really isn't cause to panic about privacy addresses and stateless autoconfig... if you don't want your salesmen to be using them, then set A=0 in prefix advertisements and set the DHCP server to hand out temporaries instead.
No, you're not going to be needing a NAT with IPv6 for normal mobile, residential and small-office usage scenarios.
I grow weary of explaining that A) NAT is not a firewall, B) your private addresses are every bit as routable as your public address when you're using a NAT gateway, and C) that just because you don't have a NAT in your cheap consumer grade IPv6 home router, it doesn't mean you won't have the cheap "simple security" functions that commonly associated with NAT gateways.
Instead, I will point you at the forthcoming RFC 6092 and its predecessor RFC 4864 and hope for the best.
p.s. Yes, you can get IPv4/NAT home routers that also route IPv6. I could recommend several alternatives, but that would be rude of me.
p.p.s. You may assume that the author of RFC 6092 knows full well that Joe User doesn't have a clue. That's the idea.
Prepare to be amazed by a sudden wave of IPv6-only mobile hosts behind broken and unreliable subscriber aggregating NAT64+DNS64 gateways that will start coming online just about the time your RIR's pool runs dry, which you will be very lucky indeed if it takes as long as five years to happen.
Or don't prepare. That way you can look brilliant when your boss says, "How is it possible you didn't see this coming and prepare for it?"
I talk with people from the majority of large carriers at IETF meetings fairly on a regular basis. I've yet to meet one who says different. As far as I know, no one in the operational community is complaining about IETF documents that recommend prefix delegation as the best current practice for commercial internet service. The 3GPP standards all assume prefix delegation to IPv6-capable mobile handsets.
Of course, if you have evidence to the contrary, I'd love to see it.
I was gonna explain all this here, but instead, I'll just drop this link. Suffice to say that there are a lot of contributors to "IPv6 brokenness" and older Mac OS X [especially pre-10.6.5] behaviors are only one of several ways that Internet users will have problems on World IPv6 Day.
This is bullshit. Every single ISP I know that offers IPv6 service today delegates a prefix. All the ones I know that are preparing commercial IPv6 services will be delegating prefixes. Even the tethering you're going to get from your IPv6-capable mobile phone will delegate a /64 prefix. Most residential providers will delegate at least a /56 and the ones run by SMART PEOPLE will delegate a /48 to each subscriber.
There is no need for residential. mobile and small-office subscribers to use NAT for IPv6.
The exception: dual-stack hosts, e.g. Mac OS X, Windows 7, iOS 4, Linux, FreeBSD, etc., on home networks with dual-stack gateways which comply with I-D.ietf-v6ops-cpe-router by advertising a unique-local IPv6 prefix even when there is no globally routable prefix available from their service provider.
Some of the newer, popular routers in the field are doing this today. Yours might be doing it right now, and you may not actually know it until World IPv6 Day arrives, when your access to Facebook, Yahoo! and Google will either be impaired or denied outright, depending on various geeky technical factors. The point of doing the World IPv6 Day exercise is to find out just how bad this problem is going to be.
On top of that, we have an excellent way to keep your teen-age daughter from running up the home phone bill with 900 services: an unlisted number! She won't be able to make trouble if she can only make outgoing calls.
If you don't want any host outside your house to communicate with your NAS box, then giving at a private address behind a NAT is the wrong thing to do. Every private address behind a NAT gateway is routable to exterior domains. If you assign a globally routable address to your NAS box, even a private one from RFC 1918, then you need a firewall to prevent it from communicating with hosts in exterior domains. (No, your cheap commodity NAT gateway is not a firewall.)
With IPv6, you can assign your NAS box a non-routable address because you don't need a NAT gateway as your home router.
Which is why many of the big content providers are doing engineering trials of dual-stack IPv4/IPv6 service, i.e. they want to be able to reach those IPv6-only subscribers. The content providers who aren't doing that will be replaced by native and local content providers who will.