Bullshit. Have a look at a graph of income inequality in the U.S. over the last fifty years. The U.S. is very different now than it was when clang_jangle was growing up. And yes, this is relevant to the originating topic.
You're also going to pass over people like me. Survived countless reductions in force without ever being laid off even once. Though, I have been on the payroll when the company closed down for good. Worked my entire career so far in jobs where even contributing a one-line patch to any open source project anywhere without prior, written, executive-level approval is a non-negotiable firing offense. I have big piles of hobby code on my home computer. I'm not allowed to post a goddamn thing to github or bitbucket or anything. I'm not even allowed to post email to developer mailing lists or join IRC channels.
Of course, that's not Paul Graham's problem. It's all mine.
I hate siding with conservative know-nothing trolls, but on this one narrow topic, he happens to be on the more correct side of the debate. (I can't say I even follow his reasoning for being on what happens to be the correct side of the debate. It seems pretty muddle-headed to me. However, the point of this debate is that first-mile network operators really do have operating costs that are a function of their number of subscribers and the network resources they consume. Denying that is pretty naïve.)
"...but they create a problem inside the large enterprise where the sysadmin wants to track his users while denying Internet-based entities the ability to do the same."
...Slowly, parts of the Internet will be become unavailable and inaccessible to you...
Yes, but this is going to happen anyway with the end of Internet neutrality. So, really, the need for end users to worry about transition to IPv6 is pretty minimal. You can safely wait until your preferred service provider network begins to insist on it.
to note that I think there is no issue on Apple's plate at all.
I wouldn't go that far. There's lots of room for improvement in the IPv6 implementation of Mac OS X 10.6. I could go on at length, but I'd probably get in trouble.
Yes, it would be better if Google were to deploy their own 6to4 relays, but when I asked their IPv6 operations people why they won't do that, their answer was basically that it would be a lot of work and it still wouldn't solve their problem. There would still be too many hosts behind 6to4 tunneling routers that are, in turn, behind firewalls that block returning protocol 41.
You should look at 6RD, which fixes all the really bad problems with 6to4 and gives service providers a proven upgrade path that doesn't force them to forklift upgrade all their IPv4-only edge router gear. We should start seeing consumer home gateway equipment and provider provisioned CPE routers that support 6RD in the not-too-distant future. Comcast is planning to use 6RD in its upcoming trials, and Google is supportive of it as well.
p1. The AirPort isn't the only CPE router that support 6to4 relay. Buffalo, D-Link and Netgear all sell devices that do the same thing.
p2. The AirPort does not enable the 6to4 tunnel by default. You have to turn it on using the "Advanced" pane of the AirPort Utility manual configuration flow.
6to4 is better than nothing if you really need to use IPv6 and you can't get a static IPv4 address for use with a tunnel broker, but it's generally not a good solution otherwise.
The real bug, of course, is not that 6to4 is preferred, it is that 6to4 is unreliable. 6to4 does not monitor its tunnels -- it just assumes that a tunnel will work if there is a global IPv4 address.
It's worse than that: 6to4 is architecturally flawed.
A 6to4 CPE router can only monitor the availability of its own 6to4 relay. It can't do anything about the relay required for the reverse path. Service providers aren't sufficiently moved to deploy their own 6to4 relays because content providers and distributors aren't deploying the reverse path relays needed to make the system functional. The content providers and distributors in turn aren't deploying 6to4 relays because there are too damned many IPv4 firewalls that drop all incoming protocol 41 on general principle, so from their perspective, it's not worth the effort.
Worth noting: Teredo suffers from the same basic architectural flaw. Neither 6to4 nor Teredo should be used, if it can be helped at all.
The root cause here is multipath confusion, but there are lots of other ways the transition will get bumpy.
Once the IPv4 address exhaustion wave starts to break, the Internet community is going to be dealing with all manner of breakage caused by some parts of the Internet resisting the transition to IPv6 while other parts are being forced into the transition by financial considerations. These different parts will be intermediated by things like NAT64 and DNS64, as well as other evils like DS-Lite and the associated AFTR boxes. Meanwhile, there will still be crazy things like 6to4 and Teredo kicking around. For the transition to go smoothly, all these interlocking parts have to work perfectly... everywhere... and we know from long experience that this just cannot happen.
This will all seem fairly familiar to anyone who survived the transition to IPv4 a generation ago. But if you're a young gun, and all you've ever known is the IPv4 we have now because the old-timers spent a long damned time years and years ago making it rock-solid before you got here, then you're about to be schooled.
Get ready for life during wartime—that's what I say.
We'd like the transition to be smooth, such that it's already complete, before IPv4 addresses run out or become rare...
At this point, the transition is either going to be a very bumpy ride, or it's not going to happen at all. Smooth is no longer an option. Get used to it.
To be fair, the worst-case catastrophic scenario involves the spill rate increasing to about 50,000 barrels per day in the event current efforts at containment fail, and further efforts to plug the hole don't work, in which case the whole reservoir empties into the gulf. That's the scenario that ends up being worse than the Valdez by a factor of about five or so.
But yes, you're right: that would suck, a lot, but not likely enough to cause a worldwide collapse of ocean ecosystems. I don't know that I feel terribly cheered by that news.
It would help if you got your facts straight. 2002:A.B.C.D::/48 is not a syntactically valid IP address notation under [RFC4291].
And yet...
p1. I don't know if you noticed this, but the presentation syntax doesn't actually appear in IPv6 headers. Addresses are converted into 128-bit binary numbers when they are sent on the medium.
p2. When I used this pidgin syntax for concision, you seemed to know what I was talking about, despite it being a violation of I-D.ietf-behave-translator-addressing, which is expected to update RFC 4291 and obsolete RFC 2765. (You should probably read those documents.)
Do you really want to make an issue out of this?
Neither of them makes 'IPv6 already has the IPv4 address space blocked off and reserved for IPv4 addresses' accurate.
You have yet to make a sound case that the accuracy of that statement is relevant to the discussion. I am trying to tell you that it isn't.
Sending an IPv6 packet to 2001:0:A.B.C.D::/64 via your V6 default gateway, does not magically mean that A.B.C.D will receive it.
Neither does sending an IPv4 packet to A.B.C.D via your default IPv4 gateway. With the Teredo addresses, your IPv6 host has the same assurance that the destination will receive it that it has with any other global scope unicast IPv6 address. i.e. if the address is reachable under local network policy, then the network will make its "best effort" to deliver it. That's the same guarantee that an IPv4 host gets. So, your point is what again?
If you're bitching that NAT64 doesn't actually require you to use the::FFFF:0:/32 IPv6-translatable prefix, which was defined over a decade ago in RFC 2765, then I don't know how to help you.
...they just have to fire up IPv6, assuming the ISP routes the packets.
Not a safe assumption. Some will run dual-stack networks. Some will run DS-Lite networks and use an AFTR. Some will just avoid IPv6 altogether and go NAT444.
When I talk to service providers, they tell me their plan is to locate HUNDREDS of subscribers per public IPv4 address and each subscriber will get a fixed persistent fraction of the TCP and UDP ports, probably only a few hundred each, allocated according to their private IPv4 address.
Believe me... users and content providers will notice this.
There's no portion of the IPv6 address space that corresponds to IPv4 addresses.
Actually, I can think of at least two in regular use right now, 2002:A.B.C.D::/48 [6to4] and 2001:0:A.B.C.D::/64 [Teredo]. And we're [IETF] busy picking over a couple other ways to encode IPv4 addresses in IPv6 address, e.g. 6RD, DNS64, and that's just the currently active working group items. The individual submissions are almost a menagerie of strange encodings. You'll note I didn't mention the V4COMPAT and V4MAPPED address ranges.
If you're going to regurgitate anti-IPv6 talking points, you could at least bother to read the latest memos. Better trolls please!
Yes, the users will notice. Have a look at what happens to the average web application when the per-subscriber port window is limited to about thirty ports on a shared IPv4 address. It isn't pretty. Subscribers who want a full global IPv4 address at their residential gateway should start getting used to paying for premium services, and content providers who expect their users to be able to get all the TCP ports they can eat from the NAT at their home gateway are about to start getting a very rude awakening.
There is no market for IP addresses. There isn't even a functioning grey market for them, and there won't even be an incentive to make one until the IANA free pool is exhausted and the RIRs begin denying IPv4 allocation requests for lack of space.
Slashdot Mirror
Bullshit. Have a look at a graph of income inequality in the U.S. over the last fifty years. The U.S. is very different now than it was when clang_jangle was growing up. And yes, this is relevant to the originating topic.
You're also going to pass over people like me. Survived countless reductions in force without ever being laid off even once. Though, I have been on the payroll when the company closed down for good. Worked my entire career so far in jobs where even contributing a one-line patch to any open source project anywhere without prior, written, executive-level approval is a non-negotiable firing offense. I have big piles of hobby code on my home computer. I'm not allowed to post a goddamn thing to github or bitbucket or anything. I'm not even allowed to post email to developer mailing lists or join IRC channels.
Of course, that's not Paul Graham's problem. It's all mine.
I hate siding with conservative know-nothing trolls, but on this one narrow topic, he happens to be on the more correct side of the debate. (I can't say I even follow his reasoning for being on what happens to be the correct side of the debate. It seems pretty muddle-headed to me. However, the point of this debate is that first-mile network operators really do have operating costs that are a function of their number of subscribers and the network resources they consume. Denying that is pretty naïve.)
Awesome. It's a battle-royale of the low UID players! (For the record, I side with jmorris42 here.)
"...but they create a problem inside the large enterprise where the sysadmin wants to track his users while denying Internet-based entities the ability to do the same."
That's why DHCP6 supports assigning temporary addresses.
...Slowly, parts of the Internet will be become unavailable and inaccessible to you...
Yes, but this is going to happen anyway with the end of Internet neutrality. So, really, the need for end users to worry about transition to IPv6 is pretty minimal. You can safely wait until your preferred service provider network begins to insist on it.
If you think the telecoms are a problem and government management would be an improvement, you need to find a friend who'll lend you a few grey cells.
Nobody is seriously arguing for the government to take over and "manage" the Internet in the USA. That's a dirty lie.
It takes years of training.
to note that I think there is no issue on Apple's plate at all.
I wouldn't go that far. There's lots of room for improvement in the IPv6 implementation of Mac OS X 10.6. I could go on at length, but I'd probably get in trouble.
Hi, Nick...
Yes, it would be better if Google were to deploy their own 6to4 relays, but when I asked their IPv6 operations people why they won't do that, their answer was basically that it would be a lot of work and it still wouldn't solve their problem. There would still be too many hosts behind 6to4 tunneling routers that are, in turn, behind firewalls that block returning protocol 41.
You should look at 6RD, which fixes all the really bad problems with 6to4 and gives service providers a proven upgrade path that doesn't force them to forklift upgrade all their IPv4-only edge router gear. We should start seeing consumer home gateway equipment and provider provisioned CPE routers that support 6RD in the not-too-distant future. Comcast is planning to use 6RD in its upcoming trials, and Google is supportive of it as well.
p1. The AirPort isn't the only CPE router that support 6to4 relay. Buffalo, D-Link and Netgear all sell devices that do the same thing.
p2. The AirPort does not enable the 6to4 tunnel by default. You have to turn it on using the "Advanced" pane of the AirPort Utility manual configuration flow.
6to4 is better than nothing if you really need to use IPv6 and you can't get a static IPv4 address for use with a tunnel broker, but it's generally not a good solution otherwise.
The real bug, of course, is not that 6to4 is preferred, it is that 6to4 is unreliable. 6to4 does not monitor its tunnels -- it just assumes that a tunnel will work if there is a global IPv4 address.
It's worse than that: 6to4 is architecturally flawed.
A 6to4 CPE router can only monitor the availability of its own 6to4 relay. It can't do anything about the relay required for the reverse path. Service providers aren't sufficiently moved to deploy their own 6to4 relays because content providers and distributors aren't deploying the reverse path relays needed to make the system functional. The content providers and distributors in turn aren't deploying 6to4 relays because there are too damned many IPv4 firewalls that drop all incoming protocol 41 on general principle, so from their perspective, it's not worth the effort.
Worth noting: Teredo suffers from the same basic architectural flaw. Neither 6to4 nor Teredo should be used, if it can be helped at all.
The root cause here is multipath confusion, but there are lots of other ways the transition will get bumpy.
Once the IPv4 address exhaustion wave starts to break, the Internet community is going to be dealing with all manner of breakage caused by some parts of the Internet resisting the transition to IPv6 while other parts are being forced into the transition by financial considerations. These different parts will be intermediated by things like NAT64 and DNS64, as well as other evils like DS-Lite and the associated AFTR boxes. Meanwhile, there will still be crazy things like 6to4 and Teredo kicking around. For the transition to go smoothly, all these interlocking parts have to work perfectly... everywhere... and we know from long experience that this just cannot happen.
This will all seem fairly familiar to anyone who survived the transition to IPv4 a generation ago. But if you're a young gun, and all you've ever known is the IPv4 we have now because the old-timers spent a long damned time years and years ago making it rock-solid before you got here, then you're about to be schooled.
Get ready for life during wartime—that's what I say.
We'd like the transition to be smooth, such that it's already complete, before IPv4 addresses run out or become rare...
At this point, the transition is either going to be a very bumpy ride, or it's not going to happen at all. Smooth is no longer an option. Get used to it.
To be fair, the worst-case catastrophic scenario involves the spill rate increasing to about 50,000 barrels per day in the event current efforts at containment fail, and further efforts to plug the hole don't work, in which case the whole reservoir empties into the gulf. That's the scenario that ends up being worse than the Valdez by a factor of about five or so.
But yes, you're right: that would suck, a lot, but not likely enough to cause a worldwide collapse of ocean ecosystems. I don't know that I feel terribly cheered by that news.
An excellent plan. Let's make it a wake.
+1.
It would help if you got your facts straight. 2002:A.B.C.D::/48 is not a syntactically valid IP address notation under [RFC4291].
And yet...
p1. I don't know if you noticed this, but the presentation syntax doesn't actually appear in IPv6 headers. Addresses are converted into 128-bit binary numbers when they are sent on the medium.
p2. When I used this pidgin syntax for concision, you seemed to know what I was talking about, despite it being a violation of I-D.ietf-behave-translator-addressing, which is expected to update RFC 4291 and obsolete RFC 2765. (You should probably read those documents.)
Do you really want to make an issue out of this?
Neither of them makes 'IPv6 already has the IPv4 address space blocked off and reserved for IPv4 addresses' accurate.
You have yet to make a sound case that the accuracy of that statement is relevant to the discussion. I am trying to tell you that it isn't.
Sending an IPv6 packet to 2001:0:A.B.C.D::/64 via your V6 default gateway, does not magically mean that A.B.C.D will receive it.
Neither does sending an IPv4 packet to A.B.C.D via your default IPv4 gateway. With the Teredo addresses, your IPv6 host has the same assurance that the destination will receive it that it has with any other global scope unicast IPv6 address. i.e. if the address is reachable under local network policy, then the network will make its "best effort" to deliver it. That's the same guarantee that an IPv4 host gets. So, your point is what again?
If you're bitching that NAT64 doesn't actually require you to use the ::FFFF:0:/32 IPv6-translatable prefix, which was defined over a decade ago in RFC 2765, then I don't know how to help you.
...they just have to fire up IPv6, assuming the ISP routes the packets.
Not a safe assumption. Some will run dual-stack networks. Some will run DS-Lite networks and use an AFTR. Some will just avoid IPv6 altogether and go NAT444.
When I talk to service providers, they tell me their plan is to locate HUNDREDS of subscribers per public IPv4 address and each subscriber will get a fixed persistent fraction of the TCP and UDP ports, probably only a few hundred each, allocated according to their private IPv4 address.
Believe me... users and content providers will notice this.
There's no portion of the IPv6 address space that corresponds to IPv4 addresses.
Actually, I can think of at least two in regular use right now, 2002:A.B.C.D::/48 [6to4] and 2001:0:A.B.C.D::/64 [Teredo]. And we're [IETF] busy picking over a couple other ways to encode IPv4 addresses in IPv6 address, e.g. 6RD, DNS64, and that's just the currently active working group items. The individual submissions are almost a menagerie of strange encodings. You'll note I didn't mention the V4COMPAT and V4MAPPED address ranges.
If you're going to regurgitate anti-IPv6 talking points, you could at least bother to read the latest memos. Better trolls please!
I'm trying to think of a reason for you to continue running IPv4 and coming up blank. Anybody? A little help here...
Yes, the users will notice. Have a look at what happens to the average web application when the per-subscriber port window is limited to about thirty ports on a shared IPv4 address. It isn't pretty. Subscribers who want a full global IPv4 address at their residential gateway should start getting used to paying for premium services, and content providers who expect their users to be able to get all the TCP ports they can eat from the NAT at their home gateway are about to start getting a very rude awakening.
Oh, you're demanding more numbers? Hold on, let me carve some more out of this bar of soap here...
You haven't thought this through very well.
There is no market for IP addresses. There isn't even a functioning grey market for them, and there won't even be an incentive to make one until the IANA free pool is exhausted and the RIRs begin denying IPv4 allocation requests for lack of space.