3. Back to point one again, it seems like someone's ego prevented any kind of transition plan or backward compatibility. The all-or-nothing attitude has prevented rollout that should have happened a decade ago
It's called dual stack. v6 deployment is not all-or-nothing. For instance, OS upgrades have been rolled out over the past decade, and content provider and ISP upgrades are being rolled out now. Take a look at Comcast, who are doing v6 despite less than 100% of their traffic being done over v6.
Except you can run both IPv4 and IPv6 over the same wire, and they won't break each other, which allows you to add IPv6 to the internet gradually. Your traffic will gradually convert from being v4 to being v6 as other people do the rollout. That's a gradual transition.
The fact that you can roll out v6 on an existing network and not lose any functionality on it, even if nobody else rolls out v6, means that it doesn't require a flag-day transition.
I guess the other way to look at it is that the lack of communication between IPv6 and IPv4 doesn't translate necessarily to a lack of communication between internet hosts, which are the things we actually care about. As such, you can't say that IPv6 is stillborn just because it doesn't integrate a means to get around the pigeon hole problem and do v4<->v6 conversations.
Plus NAT64 is a thing anyway, so if that's what you really want to do, then the option is available, with no need for it to be integrated. (Nobody uses it because dual-stack is easier, so having it available earlier wouldn't have helped v6 deployment.)
Because there are only two possibilities: a) we will be able to keep running IPv4 in the foreseeable (or at least short- and medium-term) future, or b) we will not.
You're simplifying (a) a bit too much. NAT works surprisingly well for outbound connections -- sure, we're heading towards having multiple layers of NAT, which is expensive and is going to be incredibly annoying, but in all fairness an outbound connection does tend to make it through them all.
Where is starts being a real pain is when you need inbound connections. Then it's either difficult (= expensive) or impossible to deal with NAT. (Think SIP, or multiple DNS or SMTP servers behind a single IP -- or just things like multiple web or SSH servers. Now imagine what it'll be like when your ISP puts you behind NAT, and you can't even port forward.)
So ideally, you'll be running your own servers on v6, and use the v4 purely for connecting to other people's legacy v4 servers. You can't just run your servers on v4, because the address shortage and NAT on v4 is a problem.
I think (b) is a long way out for outbound connections. But for inbound connections, it's going to be here far sooner. It's already here for some of us.
In the first case, why bother to add IPv6 to it (and spend a ton of money and manpower on that)? Just because "it's cool"?
I know you've seen it, but for thread continuity I'll link the post I made earlier, where I wall-of-text a bunch of reasons for wanting v6 even when you have v4 (the summary being that it allows you to side-step the problems in your v4 network caused by address shortages).
I'll hazard a guess and say that you've never worked as a network administrator. Or at least not one that has to explain to non-technical people why they need to spend money on technology (in which case, you have been really lucky:) ).
OK, you're right there. But I feel the start of the issue is more that the expense of dealing with NAT in v4 is ongoing and something you're already paying for, and the savings from v6 are in reducing that ongoing expense. Everybody ignores all that and concentrates on the upfront costs of a v6 rollout, because those are obvious and all they care about is next quarter's statement.
the whole idea behind compatibility is getting the thing to work without modifying the other devices that talk to it. I'm not saying that the exact same solution that was applied for BGP could be used for IP.
Right, that was where I was going. With BGP, when you pass a message to an AS (regardless of whether the destination AS is 16-bit or 32-bit, or whether or not you support 32-bit), the packet has the true destination (the IP) inside it.
It's sorta like 6to4, where the true IPv6 destination is inside the v4 packet. This style of tunneling works as backwards compatibility for BGP because BGP nodes already know how to do it, but it doesn't work for IPv6 because IPv4 nodes don't already know about it.
I believe that IPv4/IPv6 are incapable of doing this sort of backwards compatibility. The only semi-exception is...
By your own logic, IPv4 is stateless, NAT is stateful, so NAT doesn't count. Yet the world at large disagrees with you - NAT works just fine, and it is the thing that has extended IPv4's useful life by years. Yes, it has its own set of problems, and we all would like to get rid of it - but until then, it works just fine, stateful or not.
It certainly has. I wouldn't count NAT as integrated though, which was the point I was making. It's an optional thing on top.
NAT64 is the semi-exception; it's a way to get a v6 client to talk to a v4 server (but not the other way around!)
Because this "we'll just run dual stack" thing, in the end, will not lead to an IPv6-ony Internet. It will lead to a world in which most of the computers will be forced to run both IPv4 and IPv6. With network administrators being forced to maintain and update twice the number of ACLs, QoS policies, routing protocols, and so on.
...
A big "if", but your logic actually requires it. If we do dual stack, that means that we keep maintaining an IPv4 network. With all that it entails. [...] And if we're already running that network, how exactly would adding another network (Ipv6) by its side would save anything?
Definitely all true. But consider the costs involved in sticking with a v4-only network, vs a dual-stack network where you can use both v4 and v6.
(Warning: wall of text incoming.)
You've got to NAT all your traffic. This isn't free; you may need to buy some quite beefy hardware to do it fast enough. Merging two networks is a pain, because their private ranges collide. Running servers is a pain. You've got to get enough public IPs for them, which is going to start getting expensive. Or you can put them behind NAT too, but there's limits to doing that -- you can't put two DNS servers behind the same IP, say, and what are you going to do when your ISP is using CGN? You can't port forward to your servers at all then. Split DNS is a pain. Debugging problems with any of this costs money.
Having dual stack on the network allows you to side-step a lot of this. For servers that are fully internal, you don't need v4 at all. You might be able to drop v4 on servers that need external access too (maybe all the external clients are your customers, so you can force that on them -- or maybe you just don't care about losing a few viewers.) Split DNS can go away for those servers.
Merging two corporate networks? You might be able to get away without merging the v4 parts at all, if both sides have v6 -- which means no renumbering.
The less external v4 traffic you do, the less fancy your v4 NAT hardware needs to be. With v6 enabled, 50% of your traffic is v6 today. (That stat is from a big university network -- it's mostly Youtube, but still. I've heard of companies turning it on in branch offices and seeing 90% of their traffic be v6, simply because it's all internal traffic and internal servers had v6.)
Yeah, you need to keep v4 around for remote single-stack servers. But your v4 network is going to get more and more painful to manage as the ad
Administrative is how we humans pick which allocations to make. Technical is how routers see the addresses.
On the administrative side, the allocation scheme you suggest in your great-grandparent post... well, take a v4 analogy. In v4, each RIR is allocated a (or multiple) class A networks. Inside those networks, each ISPs/companies are allocated a (or multiple) class C networks. The first 8 bits are the RIR ID, the next 16 are the company ID and the last 8 are the interface identifier.
But in reality we don't actually do it like that. The RIRs get/8s, sure, but companies get/<whatever they need>, and might subnet further if they need to. You can't actually split the address up neatly into well-defined parts.
v6 is the same. The first 3 bits are "001", and we seem to have settled on/64s for subnets (mostly, but not everywhere!). But for the rest of the address?/32 is a common LIR size, unless the LIR is too big, in which case they get something bigger. And ISPs give end users anywhere from 16 to 0 subnet bits each. There is no fixed split that applies to all addresses.
On the technical side of things, the routers don't care about any of this. They scan through the routing tables looking for a match, in the same way for both v4 and v6.
v6 definitely does offer an opportunity to shorten our routing tables though. The huge address space means we can significantly reduce fragmentation -- each company only has one allocation (even if it needs to be expanded), vs needing potentially many thousands in v4. But routing happens in the same way between the two protocols.
(I'm getting quite tempted to look up the actual code that does routing in Linux, so I have something to point to as proof rather than just the circumstantial evidence of `ip` and what I've seen from using IPv6. I'll post back if I do manage to find it.)
Look, at a higher level, IPv6 was designed to be a flag day transition. [...] What I'm trying to argue is that, clearly, making IPv6 a flag day protocol was a mistake
IPv6 was not designed to be a flag day transition. It was designed to be transitioned to gradually. Tunnels were expected to be part of the transition.
We could have made IPv6 such that all applications could go IPv6 native the next day as opposed to hosts.
Do you realize what you're saying here? You're saying that upgrading the software is too difficult, so let's just upgrade all the software instead. This makes no sense.
We could have made IPv6 such that...
Hm, let's look at this from a different angle: how IPv6 was actually designed. IPv6 has a very simple backwards compatibility mechanism in it already. Basically, if you want to talk to a v4 host... you use v4. Adding v6 connectivity to a host does not affect its ability to use v4 at all. The host will be able to do everything it could before, plus it can also talk to v6 hosts.
Keep reading beyond the first phrase. And you will find this: However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it).
It sounds somewhat akin to 6to4. I'm not very familiar with BGP, but I did some thinking based on what I do know and I came to the conclusion that doing backwards compatibility the way BGP does it would be similar to the IPv4/IPv6 case if every v4 host was already aware of how to do 6to4. Since this isn't true for existing v4 hosts, and we've already established that we don't want to modify the existing hosts, it wouldn't work for IPv6.
That's what I meant; it's easy in principle because you can just map v4 into a/96 in v6.
And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".
Yes, that was the point I was making.
I'm not ignoring it - I'm saying that an IPv4-only host does not need to be able to address the entire IPv6 space in order to respond. There are translation mechanisms that allow bidirectional communication with only one side being able to initiate the connection. You might actually have heard about one - it's called NAT.
IPv6 is stateless. Any transition mechanism you want to integrate with it must also be stateless. NAT64 is stateful, so it doesn't count. You can run it on top, sure, and that can be a useful thing to do -- but the original point of your post was a complaint about something like it not being an integral part of the protocol, and I was attempting to explain why it's not possible.
You seem to be confusing "transition" with "no problem, we'll just run two completely separate networks and we'll call it transition". Some day you may realize that there is a very big difference between the two.
That is how we're doing the transition from a v4-only internet to a v6-only internet though. I'm not sure what else I can call it. Don't forget that computers can be present on both networks at the same time. It's not like it's an either/or choice (and indeed if it was, I'd agree that a mechanism of communicating between the two networks would be required.)
And think about it - if I'll have the resources, address space, knowledge and manpower to keep running that IPv4 network for as long as necessary, and everybody else will keep doing that, why exactly would I bother to dedicate more resources and manpower to run an additional, separate network (IPv6)?
That's a big "if"... but the answer is "because it saves you resources and manpower".
If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).
Well, I looked at RFC 4893 section 4.2, and the very first thing it says is Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. Is that the example you were thinking about? Because it sounds like roughly the same problem, and solution, v6 and v4 have.
No, it isn't (if you do not agree, please feel free to tell me how it is). [...] It would have been possible (simple example: reserve a particular/96 prefix in IPv6 to encompass the "legacy" IPv4 address space).
That's what I meant; it's easy in principle because you can just map v4 into a/96 in v6.
Via the pigeon hole principle
Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).
If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem.
Um... what? No, this is a huge problem. You can't just ignore it. You need bi-directional communication or it's useless. There's no point making it possible to send packets to v4 hosts with v6 if you don't also make it possible for the v4 host to respond.
Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?
OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack", which means that we run IPv4 and IPv6 on the same network, at the same time. You won't "move" to IPv6. What you do instead is add IPv6 to the network, which gives you the benefits of IPv6. Then, at some later date, you might remove v4 from the network. Of course you can't remove v4 from the network now, because you'll lose access to Slashdot -- but that's not a reason to not add IPv6 to the network, it's just a reason to not remove IPv4 from it.
That's at the administrative level, not the technical level. At the technical level, v6 routing is the same as v4 routing.
Also your table doesn't really reflect the administrative splits that we're seeing on the internet, other than the first 3 bits and the last 64 bits. For instance, many ISPs only give a/56,/60 or/64 to end users, who have a "subnet identifier" part of the address that is 8, 4 or 0 bits long.
Or similarly, ARIN allocates/32s to LIRs, but actually reserves a/29 for them -- for instance, take the allocations around 2001:470::/32: the next 7/32s are unallocated, and the next allocation is 2001:478::/32. The next one after that is 2001:480::/32. In this case ARIN have reserved 3 bits for expansion of the/32s -- but note that this isn't nasty routing stuff, the space is being left deliberately so as to avoid nasty routing fragmentation in the future.
You've got the right idea in the sense that allocations are heirarchical, but the strict bit boundaries are mostly ignored. And it's all administrative anyway; the computers doing the routing couldn't care less.
Woah, woah, woah. We don't hate home routers. Routers are absolutely essential for the internet. It couldn't function at its current scale without routers. Every home should have a router on-site. Any ISP rolling out v6 in a way that prevents users from having their own routers is doing it wrong and they suck. Routers are nice. We want more routing in the world, not less!
What we don't want is ubiquous NAT on all those routers. NAT is just a pain, it breaks a huge ton of stuff without giving you any advantages in return. We need to get away from that.
That said, you can certainly do some nifty and useful things with NAT64 and NAT46, like allowing remote v6 nodes to connect to a local v4-only legacy device. I do that myself to poll my managed switch with SNMP. That's a useful ability for a router to have. But by default, just push v6 to your end hosts without using NAT. Pretty much all of them support v6 themselves just fine.
No... The routing process isn't close to the same. There is no capability in IPv6 for a routing table. That goes away. A router handling a particular route is simply implementing a particular bit.
Uhh... what. No. Routing in v6 is fundamentally the same as in v4. v6 has routing tables. Take a look at `ip -4 route show` and `ip -6 route show` on a dual-stack Linux router (or just look at the manpage for the syntax for manipulating the tables) and you'll see how similar they are.
It'll look something like this, based on the output from my own router:
~# ip -4 route show
198.51.100.0/24 dev eth1 proto kernel scope link src 198.51.100.148
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
default via 198.51.100.1 dev eth1
~# ip -6 route show
2001:470:db8:42::/64 via:: dev eth1 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295
2001:470:91f3:1::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:470:db8:42::1 dev eth1 metric 1024 mtu 1480 advmss 1420 hoplimit 4294967295
As I said, we map many IPv6 addresses into a single IPv4 and use encapsulation to encode the remaining part. Not unlike NATs which use the local address translation table to tease apart many things being mapped to a single IP address, but in this case we use the extra bits encapsulated in the packet.
Once the packet reaches a fully IPv6 capable node it gets send on IPv6
This, right here, is exactly how 6to4 works.
or we use private address space for the journey to complete over IPv4, again, not unlike NATs.
This isn't. This is basically a NAT64 (or NAT46, rather) step on top. It's not really worth it in the general case; just do native v6 over this part, unless there's some real reason you can't do v6 on the hosts (if you're still on Linux 2.2, for instance).
What I keep trying to tell you is that the ideas you're complaining we "should have done", have in fact been done already. They're not integrated directly into v6 because that would make no sense; 6to4 as a tunnelling protocol is transparent to the IPv6 side and is thus optional (and it would be very bad if it wasn't, since we'd be forced to deal with the limited space and fragmentation in v4 until the end of time -- instead we can get rid of it as each network goes native v6) and NAT46 is stateful, which is obviously not doable in a stateless L3 protocol.
These things are available, and have always been part of the intended transition mechanisms for v6.
Well, it is backwards compatible. There's a "version" field in the IP header, just set that to 4 for v4 and 6 for v6. You can run both of those over the same link and neither will break the other. Any v6 host that wants to speak to a v4 host just has to do it with v4. It's very simple.
The real problem, however, is getting an IPv6-only host to communicate with an IPv4-only host. Until we have that, there is no backward compatibility to speak of.
OK, there are two ways I could respond to this, depending on what you meant by "IPv4-only host". Did you mean a v6-capable host that has no v6 connectivity? In which case the answer is 6to4. That's how a host that understands v6 but has no v6 connectivity can send and receive packets to v6 hosts over a v4-only network.
But perhaps what you were really trying to say is that you want this communication to happen with a computer with no v6 stack (e.g. something running Linux 2.2), or with an unconfigured/disabled v6 stack. In other words, you want a way for v4 hosts to send packets using v4 to v6 addresses, and a way for v6 hosts to send packets using v6 to v4 addresses, and you want to do it without updating legacy v4-only OSs. The v6->v4 case is easy enough. The problem is the v4->v6 case. Via the pidgeon hole principle, it's fundamentally impossible to specify which v6 computer you want to send a packet to using v4 alone, because there's just not enough address bits in v4 to specify the destination.
This impossibility is why IPv6 has no way to do it.
I don't because I can't - Nothing I have supports IPv6 and until someone makes a router capable of NAT'ing between IPv6 and IPv4 I'm basically stuck.
Really?
Do you use Windows? Because that supports IPv6, since XP. If not, then maybe Linux? That supports IPv6, since 2.4. Or if not that, then maybe OSX, which supports IPv6 since... er, dunno, 10.something. Heck, the BSDs support IPv6, even though they've been dying for years.
If they don't speak IPv6 they simply route the packet as if it was IPv4
This is true for intermediate routers, as it is with 6to4.
Only the host destination needs to speak IPv6
The source needs to understand it too, and if you're updating the source to understand this interop method then your source is no longer v4-only.
and since it is addressed to a port, it does not require the IP stack to speak IPv6, only the server listening to that port
This doesn't even make any sense. If you could send the traffic to the server in the first place, why bother with all this tunnelling of extra bits? Just send your traffic to the server and be done with it!
The packet traverses then to the 4to6 gateway over IPv4 where it is opened and the rest of the IPv6 address is recovered from within the encapsulation
OK, so that's 6to4.
The gatway uses that part to route the packet for the next leg of the trip.
6to4.
This is the exact same trick used by virtual switching in ATM networks as well as MPLS.
To be fair, a 32-bit process with the LARGEADDRESSAWARE flag running on 64-bit Windows will have access to 4 GB of address space. Even for heavy Firefox users, 4 GB of memory generally ought to be enough if you decide ignore the effects of memory fragmentation.
No, we do. Incorrect grammar has a tendency to spread; people use it because they've read it elsewhere so often that it pops to mind when they're writing text themselves. I even find that I'm beginning to think "it's" for the possessive form of "it", because that error is so damn pervasive.
Many people, when called on bad grammar, will use the defence that "nobody cares so I'm just going to continue being wrong". If the GP wants to go around correcting them of that notion, then I will support him in that.
For a desktop, I'd say single-threaded speed is more important than total multi-threaded speed The performance of most things you interact with is dependent on single-threaded speed -- browsers, office suites or in general pretty much anything that happens in response to mouse/keyboard input. Things that benefit the most from arbitrary amounts of cores are usually things like compression, video encoding, rendering... things where you start the task and come back later. If you're doing that heavily then it makes sense to buy a many-core CPU, but for regular desktop use you want something that minimizes interaction latency -- fewer cores and higher per-core performance is better.
Of course, as you say, our desktops are often doing more than one thing at once, so >1 core is useful. No use having a fast processor if your interactive task has to wait for something else to finish first. Single core systems are also prone to having a single task eat all your CPU, rendering the entire system unusable until it's finished (although you could argue that's more a problem with the OS scheduler). There comes a point of diminishing returns though, and I think 8 cores is beyond that point. I'd rather have a 4-core processor with faster single-threaded performance than an 8-core one with higher total aggregate performance.
I don't think cost is even in AMD's favor either. It looks like Intel chips are using significantly less power for the same performance, so if you're paying for electricity then Intel will be cheaper in the long run. This review paints a pretty bleak picture for AMD.
About the only thing AMD have going for them right now is that they're not Intel. Intel's trick of not selling any CPU models with all features enabled (there's only a couple of models with unlocked multipliers, and those models have some "business class" features, which I happen to want, disabled) annoys me. But if I built a new desktop now, looking at AMD's current CPU offerings, I'm not sure even being made by Intel would be enough to stop me from buying an Intel chip.
Hm, so, the GP says that it slightly outperforms the i5 2500k in things that use all 8 threads, and you attempt to debunk him with... a benchmark that uses all 8 threads? In which the AMD chip beats the Intel one by a fairly minor 8%?
Seems to me like he may have a point. What's the single-threaded performance like?
Think about email. When you want to send mail to somebody, you just pull up your email account and do it. No fuss. You don't need to sign up for a Gmail account, a Hotmail account, an Outlook account, a Yahoo account, a gmx.net account and so on for every provider just to be able to send email to that provider's users. One account with one of them is enough to email a user of any of them.
Social networking isn't like that at the moment. You have to sign up for separate Facebook, Google+, Twitter, Nexopia, Badoo, Bebo and so on accounts just to interact with the users of those networks. This is bad.
To see why, just look at Gmail. Back when that was introduced, Hotmail was the go-to provider for free webmail. I don't know if you remember, but at the time Hotmail kinda sucked. It had an ugly, slow interface and an allowance of 2-4 MB. That was standard. Then Gmail comes along with a clean, responsive interface and a 1 GB allowance, and of course it's massively popular. Suddenly every other provider was cleaning up their UI and offering much larger allowances. Outlook.com, for instance, now has the clean, responsive interface and it doesn't even have a cap on the amount of mail you can store.
If email wasn't federated, none of that would have happened. Nobody would have used or cared about Gmail back when it had no users because, well, it had no users. You'd still be using Hotmail with its 2 MB inbox. You couldn't even set up your own server to avoid all that, because your own server would be useless for mailing Hotmail users.
Diaspora aims to bring federation to social networks, and that's why you should care about it.
Slashdot Mirror
It's called dual stack. v6 deployment is not all-or-nothing. For instance, OS upgrades have been rolled out over the past decade, and content provider and ISP upgrades are being rolled out now. Take a look at Comcast, who are doing v6 despite less than 100% of their traffic being done over v6.
Except you can run both IPv4 and IPv6 over the same wire, and they won't break each other, which allows you to add IPv6 to the internet gradually. Your traffic will gradually convert from being v4 to being v6 as other people do the rollout. That's a gradual transition.
The fact that you can roll out v6 on an existing network and not lose any functionality on it, even if nobody else rolls out v6, means that it doesn't require a flag-day transition.
I guess the other way to look at it is that the lack of communication between IPv6 and IPv4 doesn't translate necessarily to a lack of communication between internet hosts, which are the things we actually care about. As such, you can't say that IPv6 is stillborn just because it doesn't integrate a means to get around the pigeon hole problem and do v4<->v6 conversations.
Plus NAT64 is a thing anyway, so if that's what you really want to do, then the option is available, with no need for it to be integrated. (Nobody uses it because dual-stack is easier, so having it available earlier wouldn't have helped v6 deployment.)
Because there are only two possibilities: a) we will be able to keep running IPv4 in the foreseeable (or at least short- and medium-term) future, or b) we will not.
You're simplifying (a) a bit too much. NAT works surprisingly well for outbound connections -- sure, we're heading towards having multiple layers of NAT, which is expensive and is going to be incredibly annoying, but in all fairness an outbound connection does tend to make it through them all.
Where is starts being a real pain is when you need inbound connections. Then it's either difficult (= expensive) or impossible to deal with NAT. (Think SIP, or multiple DNS or SMTP servers behind a single IP -- or just things like multiple web or SSH servers. Now imagine what it'll be like when your ISP puts you behind NAT, and you can't even port forward.)
So ideally, you'll be running your own servers on v6, and use the v4 purely for connecting to other people's legacy v4 servers. You can't just run your servers on v4, because the address shortage and NAT on v4 is a problem.
I think (b) is a long way out for outbound connections. But for inbound connections, it's going to be here far sooner. It's already here for some of us.
In the first case, why bother to add IPv6 to it (and spend a ton of money and manpower on that)? Just because "it's cool"?
I know you've seen it, but for thread continuity I'll link the post I made earlier, where I wall-of-text a bunch of reasons for wanting v6 even when you have v4 (the summary being that it allows you to side-step the problems in your v4 network caused by address shortages).
I'll hazard a guess and say that you've never worked as a network administrator. Or at least not one that has to explain to non-technical people why they need to spend money on technology (in which case, you have been really lucky :) ).
OK, you're right there. But I feel the start of the issue is more that the expense of dealing with NAT in v4 is ongoing and something you're already paying for, and the savings from v6 are in reducing that ongoing expense. Everybody ignores all that and concentrates on the upfront costs of a v6 rollout, because those are obvious and all they care about is next quarter's statement.
the whole idea behind compatibility is getting the thing to work without modifying the other devices that talk to it. I'm not saying that the exact same solution that was applied for BGP could be used for IP.
Right, that was where I was going. With BGP, when you pass a message to an AS (regardless of whether the destination AS is 16-bit or 32-bit, or whether or not you support 32-bit), the packet has the true destination (the IP) inside it.
It's sorta like 6to4, where the true IPv6 destination is inside the v4 packet. This style of tunneling works as backwards compatibility for BGP because BGP nodes already know how to do it, but it doesn't work for IPv6 because IPv4 nodes don't already know about it.
I believe that IPv4/IPv6 are incapable of doing this sort of backwards compatibility. The only semi-exception is...
By your own logic, IPv4 is stateless, NAT is stateful, so NAT doesn't count. Yet the world at large disagrees with you - NAT works just fine, and it is the thing that has extended IPv4's useful life by years. Yes, it has its own set of problems, and we all would like to get rid of it - but until then, it works just fine, stateful or not.
It certainly has. I wouldn't count NAT as integrated though, which was the point I was making. It's an optional thing on top.
NAT64 is the semi-exception; it's a way to get a v6 client to talk to a v4 server (but not the other way around!)
Because this "we'll just run dual stack" thing, in the end, will not lead to an IPv6-ony Internet. It will lead to a world in which most of the computers will be forced to run both IPv4 and IPv6. With network administrators being forced to maintain and update twice the number of ACLs, QoS policies, routing protocols, and so on.
...
A big "if", but your logic actually requires it. If we do dual stack, that means that we keep maintaining an IPv4 network. With all that it entails. [...] And if we're already running that network, how exactly would adding another network (Ipv6) by its side would save anything?
Definitely all true. But consider the costs involved in sticking with a v4-only network, vs a dual-stack network where you can use both v4 and v6.
(Warning: wall of text incoming.)
You've got to NAT all your traffic. This isn't free; you may need to buy some quite beefy hardware to do it fast enough. Merging two networks is a pain, because their private ranges collide. Running servers is a pain. You've got to get enough public IPs for them, which is going to start getting expensive. Or you can put them behind NAT too, but there's limits to doing that -- you can't put two DNS servers behind the same IP, say, and what are you going to do when your ISP is using CGN? You can't port forward to your servers at all then. Split DNS is a pain. Debugging problems with any of this costs money.
Having dual stack on the network allows you to side-step a lot of this. For servers that are fully internal, you don't need v4 at all. You might be able to drop v4 on servers that need external access too (maybe all the external clients are your customers, so you can force that on them -- or maybe you just don't care about losing a few viewers.) Split DNS can go away for those servers.
Merging two corporate networks? You might be able to get away without merging the v4 parts at all, if both sides have v6 -- which means no renumbering.
The less external v4 traffic you do, the less fancy your v4 NAT hardware needs to be. With v6 enabled, 50% of your traffic is v6 today. (That stat is from a big university network -- it's mostly Youtube, but still. I've heard of companies turning it on in branch offices and seeing 90% of their traffic be v6, simply because it's all internal traffic and internal servers had v6.)
Yeah, you need to keep v4 around for remote single-stack servers. But your v4 network is going to get more and more painful to manage as the ad
Administrative is how we humans pick which allocations to make. Technical is how routers see the addresses.
On the administrative side, the allocation scheme you suggest in your great-grandparent post... well, take a v4 analogy. In v4, each RIR is allocated a (or multiple) class A networks. Inside those networks, each ISPs/companies are allocated a (or multiple) class C networks. The first 8 bits are the RIR ID, the next 16 are the company ID and the last 8 are the interface identifier.
But in reality we don't actually do it like that. The RIRs get /8s, sure, but companies get /<whatever they need>, and might subnet further if they need to. You can't actually split the address up neatly into well-defined parts.
v6 is the same. The first 3 bits are "001", and we seem to have settled on /64s for subnets (mostly, but not everywhere!). But for the rest of the address? /32 is a common LIR size, unless the LIR is too big, in which case they get something bigger. And ISPs give end users anywhere from 16 to 0 subnet bits each. There is no fixed split that applies to all addresses.
On the technical side of things, the routers don't care about any of this. They scan through the routing tables looking for a match, in the same way for both v4 and v6.
v6 definitely does offer an opportunity to shorten our routing tables though. The huge address space means we can significantly reduce fragmentation -- each company only has one allocation (even if it needs to be expanded), vs needing potentially many thousands in v4. But routing happens in the same way between the two protocols.
(I'm getting quite tempted to look up the actual code that does routing in Linux, so I have something to point to as proof rather than just the circumstantial evidence of `ip` and what I've seen from using IPv6. I'll post back if I do manage to find it.)
Look, at a higher level, IPv6 was designed to be a flag day transition. [...] What I'm trying to argue is that, clearly, making IPv6 a flag day protocol was a mistake
IPv6 was not designed to be a flag day transition. It was designed to be transitioned to gradually. Tunnels were expected to be part of the transition.
We could have made IPv6 such that all applications could go IPv6 native the next day as opposed to hosts.
Do you realize what you're saying here? You're saying that upgrading the software is too difficult, so let's just upgrade all the software instead. This makes no sense.
We could have made IPv6 such that...
Hm, let's look at this from a different angle: how IPv6 was actually designed. IPv6 has a very simple backwards compatibility mechanism in it already. Basically, if you want to talk to a v4 host... you use v4. Adding v6 connectivity to a host does not affect its ability to use v4 at all. The host will be able to do everything it could before, plus it can also talk to v6 hosts.
Why is this insufficient?
Keep reading beyond the first phrase. And you will find this: However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it).
It sounds somewhat akin to 6to4. I'm not very familiar with BGP, but I did some thinking based on what I do know and I came to the conclusion that doing backwards compatibility the way BGP does it would be similar to the IPv4/IPv6 case if every v4 host was already aware of how to do 6to4. Since this isn't true for existing v4 hosts, and we've already established that we don't want to modify the existing hosts, it wouldn't work for IPv6.
That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.
And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".
Yes, that was the point I was making.
I'm not ignoring it - I'm saying that an IPv4-only host does not need to be able to address the entire IPv6 space in order to respond. There are translation mechanisms that allow bidirectional communication with only one side being able to initiate the connection. You might actually have heard about one - it's called NAT.
IPv6 is stateless. Any transition mechanism you want to integrate with it must also be stateless. NAT64 is stateful, so it doesn't count. You can run it on top, sure, and that can be a useful thing to do -- but the original point of your post was a complaint about something like it not being an integral part of the protocol, and I was attempting to explain why it's not possible.
You seem to be confusing "transition" with "no problem, we'll just run two completely separate networks and we'll call it transition". Some day you may realize that there is a very big difference between the two.
That is how we're doing the transition from a v4-only internet to a v6-only internet though. I'm not sure what else I can call it. Don't forget that computers can be present on both networks at the same time. It's not like it's an either/or choice (and indeed if it was, I'd agree that a mechanism of communicating between the two networks would be required.)
And think about it - if I'll have the resources, address space, knowledge and manpower to keep running that IPv4 network for as long as necessary, and everybody else will keep doing that, why exactly would I bother to dedicate more resources and manpower to run an additional, separate network (IPv6)?
That's a big "if"... but the answer is "because it saves you resources and manpower".
If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).
Well, I looked at RFC 4893 section 4.2, and the very first thing it says is Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. Is that the example you were thinking about? Because it sounds like roughly the same problem, and solution, v6 and v4 have.
No, it isn't (if you do not agree, please feel free to tell me how it is). [...] It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space).
That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.
Via the pigeon hole principle
Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).
If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem.
Um... what? No, this is a huge problem. You can't just ignore it. You need bi-directional communication or it's useless. There's no point making it possible to send packets to v4 hosts with v6 if you don't also make it possible for the v4 host to respond.
Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?
OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack", which means that we run IPv4 and IPv6 on the same network, at the same time. You won't "move" to IPv6. What you do instead is add IPv6 to the network, which gives you the benefits of IPv6. Then, at some later date, you might remove v4 from the network. Of course you can't remove v4 from the network now, because you'll lose access to Slashdot -- but that's not a reason to not add IPv6 to the network, it's just a reason to not remove IPv4 from it.
Looks like it's not a formal standard. I found this mailing list post which links to this IETF draft text which mentions them on page 5.
That's at the administrative level, not the technical level. At the technical level, v6 routing is the same as v4 routing.
Also your table doesn't really reflect the administrative splits that we're seeing on the internet, other than the first 3 bits and the last 64 bits. For instance, many ISPs only give a /56, /60 or /64 to end users, who have a "subnet identifier" part of the address that is 8, 4 or 0 bits long.
Or similarly, ARIN allocates /32s to LIRs, but actually reserves a /29 for them -- for instance, take the allocations around 2001:470::/32: the next 7 /32s are unallocated, and the next allocation is 2001:478::/32. The next one after that is 2001:480::/32. In this case ARIN have reserved 3 bits for expansion of the /32s -- but note that this isn't nasty routing stuff, the space is being left deliberately so as to avoid nasty routing fragmentation in the future.
There's also the IANA global unicast address assignment list, which has allocations from all over the shop.
You've got the right idea in the sense that allocations are heirarchical, but the strict bit boundaries are mostly ignored. And it's all administrative anyway; the computers doing the routing couldn't care less.
Woah, woah, woah. We don't hate home routers. Routers are absolutely essential for the internet. It couldn't function at its current scale without routers. Every home should have a router on-site. Any ISP rolling out v6 in a way that prevents users from having their own routers is doing it wrong and they suck. Routers are nice. We want more routing in the world, not less!
What we don't want is ubiquous NAT on all those routers. NAT is just a pain, it breaks a huge ton of stuff without giving you any advantages in return. We need to get away from that.
That said, you can certainly do some nifty and useful things with NAT64 and NAT46, like allowing remote v6 nodes to connect to a local v4-only legacy device. I do that myself to poll my managed switch with SNMP. That's a useful ability for a router to have. But by default, just push v6 to your end hosts without using NAT. Pretty much all of them support v6 themselves just fine.
No... The routing process isn't close to the same. There is no capability in IPv6 for a routing table. That goes away. A router handling a particular route is simply implementing a particular bit.
Uhh... what. No. Routing in v6 is fundamentally the same as in v4. v6 has routing tables. Take a look at `ip -4 route show` and `ip -6 route show` on a dual-stack Linux router (or just look at the manpage for the syntax for manipulating the tables) and you'll see how similar they are.
It'll look something like this, based on the output from my own router:
~# ip -4 route show
:: dev eth1 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295
198.51.100.0/24 dev eth1 proto kernel scope link src 198.51.100.148
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
default via 198.51.100.1 dev eth1
~# ip -6 route show
2001:470:db8:42::/64 via
2001:470:91f3:1::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:470:db8:42::1 dev eth1 metric 1024 mtu 1480 advmss 1420 hoplimit 4294967295
No real difference there.
As I said, we map many IPv6 addresses into a single IPv4 and use encapsulation to encode the remaining part. Not unlike NATs which use the local address translation table to tease apart many things being mapped to a single IP address, but in this case we use the extra bits encapsulated in the packet.
Once the packet reaches a fully IPv6 capable node it gets send on IPv6
This, right here, is exactly how 6to4 works.
or we use private address space for the journey to complete over IPv4, again, not unlike NATs.
This isn't. This is basically a NAT64 (or NAT46, rather) step on top. It's not really worth it in the general case; just do native v6 over this part, unless there's some real reason you can't do v6 on the hosts (if you're still on Linux 2.2, for instance).
What I keep trying to tell you is that the ideas you're complaining we "should have done", have in fact been done already. They're not integrated directly into v6 because that would make no sense; 6to4 as a tunnelling protocol is transparent to the IPv6 side and is thus optional (and it would be very bad if it wasn't, since we'd be forced to deal with the limited space and fragmentation in v4 until the end of time -- instead we can get rid of it as each network goes native v6) and NAT46 is stateful, which is obviously not doable in a stateless L3 protocol.
These things are available, and have always been part of the intended transition mechanisms for v6.
Well, it is backwards compatible. There's a "version" field in the IP header, just set that to 4 for v4 and 6 for v6. You can run both of those over the same link and neither will break the other. Any v6 host that wants to speak to a v4 host just has to do it with v4. It's very simple.
The real problem, however, is getting an IPv6-only host to communicate with an IPv4-only host. Until we have that, there is no backward compatibility to speak of.
OK, there are two ways I could respond to this, depending on what you meant by "IPv4-only host". Did you mean a v6-capable host that has no v6 connectivity? In which case the answer is 6to4. That's how a host that understands v6 but has no v6 connectivity can send and receive packets to v6 hosts over a v4-only network.
But perhaps what you were really trying to say is that you want this communication to happen with a computer with no v6 stack (e.g. something running Linux 2.2), or with an unconfigured/disabled v6 stack. In other words, you want a way for v4 hosts to send packets using v4 to v6 addresses, and a way for v6 hosts to send packets using v6 to v4 addresses, and you want to do it without updating legacy v4-only OSs. The v6->v4 case is easy enough. The problem is the v4->v6 case. Via the pidgeon hole principle, it's fundamentally impossible to specify which v6 computer you want to send a packet to using v4 alone, because there's just not enough address bits in v4 to specify the destination.
This impossibility is why IPv6 has no way to do it.
I don't because I can't - Nothing I have supports IPv6 and until someone makes a router capable of NAT'ing between IPv6 and IPv4 I'm basically stuck.
Really?
Do you use Windows? Because that supports IPv6, since XP. If not, then maybe Linux? That supports IPv6, since 2.4. Or if not that, then maybe OSX, which supports IPv6 since... er, dunno, 10.something. Heck, the BSDs support IPv6, even though they've been dying for years.
I'm pretty sure you use stuff that supports IPv6.
If they don't speak IPv6 they simply route the packet as if it was IPv4
This is true for intermediate routers, as it is with 6to4.
Only the host destination needs to speak IPv6
The source needs to understand it too, and if you're updating the source to understand this interop method then your source is no longer v4-only.
and since it is addressed to a port, it does not require the IP stack to speak IPv6, only the server listening to that port
This doesn't even make any sense. If you could send the traffic to the server in the first place, why bother with all this tunnelling of extra bits? Just send your traffic to the server and be done with it!
The packet traverses then to the 4to6 gateway over IPv4 where it is opened and the rest of the IPv6 address is recovered from within the encapsulation
OK, so that's 6to4.
The gatway uses that part to route the packet for the next leg of the trip.
6to4.
This is the exact same trick used by virtual switching in ATM networks as well as MPLS.
And also -- you guessed it -- 6to4.
6to4 does not facilitate interoperation between IPv4-only hosts and IPv6-only hosts.
Neither does your idea. It requires that v4-only hosts be taught how to speak it, the same as 6to4 does.
Moreover, 6to4 encapsulates IPv4 addresses in IPv6 2002: addresses, which is the reverse of what I'm suggesting.
Surely you are not suggesting that we encapsulate v6 addresses inside v4 addresses. That's not going to work.
The right-most octet in the abbreviated address substitutes for the right-most octets of the full address.
e.g.:
127.1 -> 127.0.0.1
192.168.1 -> 192.168.0.1
192.168.257 -> 192.168.1.1
10.65536 -> 10.1.0.0
You've pretty much just described 6to4. We have it already.
XP x64 does not run 16-bit Windows programs. I assume it doesn't run any DOS executables either but I don't have any handy to test with.
To be fair, a 32-bit process with the LARGEADDRESSAWARE flag running on 64-bit Windows will have access to 4 GB of address space. Even for heavy Firefox users, 4 GB of memory generally ought to be enough if you decide ignore the effects of memory fragmentation.
So there will be no overflow until 2156.
Or 19256, as some of those systems would display that year as.
No, we do. Incorrect grammar has a tendency to spread; people use it because they've read it elsewhere so often that it pops to mind when they're writing text themselves. I even find that I'm beginning to think "it's" for the possessive form of "it", because that error is so damn pervasive.
Many people, when called on bad grammar, will use the defence that "nobody cares so I'm just going to continue being wrong". If the GP wants to go around correcting them of that notion, then I will support him in that.
For a desktop, I'd say single-threaded speed is more important than total multi-threaded speed The performance of most things you interact with is dependent on single-threaded speed -- browsers, office suites or in general pretty much anything that happens in response to mouse/keyboard input. Things that benefit the most from arbitrary amounts of cores are usually things like compression, video encoding, rendering... things where you start the task and come back later. If you're doing that heavily then it makes sense to buy a many-core CPU, but for regular desktop use you want something that minimizes interaction latency -- fewer cores and higher per-core performance is better.
Of course, as you say, our desktops are often doing more than one thing at once, so >1 core is useful. No use having a fast processor if your interactive task has to wait for something else to finish first. Single core systems are also prone to having a single task eat all your CPU, rendering the entire system unusable until it's finished (although you could argue that's more a problem with the OS scheduler). There comes a point of diminishing returns though, and I think 8 cores is beyond that point. I'd rather have a 4-core processor with faster single-threaded performance than an 8-core one with higher total aggregate performance.
I don't think cost is even in AMD's favor either. It looks like Intel chips are using significantly less power for the same performance, so if you're paying for electricity then Intel will be cheaper in the long run. This review paints a pretty bleak picture for AMD.
About the only thing AMD have going for them right now is that they're not Intel. Intel's trick of not selling any CPU models with all features enabled (there's only a couple of models with unlocked multipliers, and those models have some "business class" features, which I happen to want, disabled) annoys me. But if I built a new desktop now, looking at AMD's current CPU offerings, I'm not sure even being made by Intel would be enough to stop me from buying an Intel chip.
Hm, so, the GP says that it slightly outperforms the i5 2500k in things that use all 8 threads, and you attempt to debunk him with... a benchmark that uses all 8 threads? In which the AMD chip beats the Intel one by a fairly minor 8%?
Seems to me like he may have a point. What's the single-threaded performance like?
Everybody; because it's federated.
Think about email. When you want to send mail to somebody, you just pull up your email account and do it. No fuss. You don't need to sign up for a Gmail account, a Hotmail account, an Outlook account, a Yahoo account, a gmx.net account and so on for every provider just to be able to send email to that provider's users. One account with one of them is enough to email a user of any of them.
Social networking isn't like that at the moment. You have to sign up for separate Facebook, Google+, Twitter, Nexopia, Badoo, Bebo and so on accounts just to interact with the users of those networks. This is bad.
To see why, just look at Gmail. Back when that was introduced, Hotmail was the go-to provider for free webmail. I don't know if you remember, but at the time Hotmail kinda sucked. It had an ugly, slow interface and an allowance of 2-4 MB. That was standard. Then Gmail comes along with a clean, responsive interface and a 1 GB allowance, and of course it's massively popular. Suddenly every other provider was cleaning up their UI and offering much larger allowances. Outlook.com, for instance, now has the clean, responsive interface and it doesn't even have a cap on the amount of mail you can store.
If email wasn't federated, none of that would have happened. Nobody would have used or cared about Gmail back when it had no users because, well, it had no users. You'd still be using Hotmail with its 2 MB inbox. You couldn't even set up your own server to avoid all that, because your own server would be useless for mailing Hotmail users.
Diaspora aims to bring federation to social networks, and that's why you should care about it.