Not the best kind of publicity to have when you require always-on DRM for your games..."
Link to Original Source
It was designed to be transitioned to gradually.
Nope. For all the reasons I explained to you previously, chief being the fact that IPv6 is 100% incompatible with IPv4 on the wire.
Tunnels were expected to be part of the transition.
True. And just as true is the fact that tunnels only solve half the problem. Yes, they help getting new IPv6 hosts to talk to each other (over a potentially non-IPv6 compliant infrastructure). But they do not solve the bigger issue - getting new IPv6 hosts to talk to existing IPv4-only hosts (like, I don't know... the entire Internet?!).
IPv6 has a very simple backwards compatibility mechanism in it already. Basically, if you want to talk to a v4 host... you use v4.
And once again, I strongly suggest that you should read and understand the term "compatibility". I'll give you a hint: "just use the old protocol at the same time" isn't it!
Why is this insufficient?
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.
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"?
And in the second case, there's no way to do dual stack anymore - and where's your "simple mechanism" then?
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
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.
In one of my previous posts, I linked to the definition of http://en.wikipedia.org/wiki/Backward_compatibility. You either didn't read it, or didn't understand it - 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. They are completely different protocols, with different sets of rules. I just gave you two examples of what real compatibility looks like, since you still seem to believe that 6to4 offers it.
IPv6 is stateless. Any transition mechanism you want to integrate with it must also be stateless. NAT64 is stateful, so it doesn't count.
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.
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.
Totally agree with you - it's basically the only solution we have right now. But the fact that it's the only solution doesn't make it a good one. 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.
And before you say "no problem, at that point we'll just turn off IPv4!", keep in mind that this will not be possible until there is no IPv4 Internet to speak of. How long do you think that will be? My guess would be on the order of decades...
That's a big "if"... but the answer is "because it saves you resources and manpower".
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? Please don't forget that we are talking about the transition here - that transition being done by using dual stack.
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.
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).
This is called actually the important part of the transition strategy. And it is completely missing in IPv6.
That's what I meant; it's easy in principle because you can just map v4 into a
And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".
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.
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.
OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack"
No need for sarcasm - I really don't feel the need for this to degenerate into a flame war. 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.
And yes, dual stack does exactly that - run two separate networks, totally separate from each other ("ships in the night"). 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 (your misnamed "transition period"), 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)?
The right-most octet in the abbreviated address substitutes for the right-most octets of the full address.
Do you have a reference for that? I did notice the behavior in operating systems ("ping 127.1" translates to "ping 127.0.0.1" in both Windows and Linux), but I was never able to find an RFC that talks about it.
There is no capability in IPv6 for a routing table. That goes away.
No it doesn't. And it cannot. There still is a routing table, it's just... bigger
In fact, one of the major selling points of IPv6 is that the subnetting and routing remain the same as in IPv4 (making things a bit easier to understand for administrators).
So if I'm sending a packet to you in v6 and we disagree on 37 bits there are 37 virtual routers (there may be more one virtual router implemented on a physical router) between you and I exactly.
That makes no sense to me. Do you have any kind of reference for the idea that "a bit in the address = a virtual router"?
IPv6 A wants to talk to IPv4 B:
1) A gets a dynamic IPv4 addresses assigned to it (unless (4) below).
Congratulations - your IPv6-only is now also an IPv4 host! That does not solve the original problem - getting an IPv6-only host to talk to an IPv4-only host. Aka "compatibility".
What is not the case though, what started the discussion with GP is that every v6 address is reachable by v4. As traffic moves to v6, a smaller percentage of v6 services will be offered on the v4 internet, and v4 will become a less and less functional subset of the internet. That's good, that's what we want.
I completely agree with you there (see a previous comment of mine). Getting stuff on the IPv6-only Internet might actually persuade a lot of host owners to upgrade.
Until we have an IPv6 Internet however, we need to make sure that people who move to IPv6 can still access the existing IPv4-only services. This is where the v6-to-v4 compatibility is necessary. And that compatibility was completely overlooked.
And no, "just add an IPv4 address to your host" doesn't cut it. If I'm going to have to run IPv4 to access my services, why bother with IPv6 at all?
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.
I suggest you have a look at the term "backward compatibility", and try to understand what I am talking about. Quote: "a product or technology is backward or downward compatible if it can work with input generated by an older product or technology.".
Simply specifying a version number does NOT make a product backward compatible.
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).
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.
Exactly. Because there is no way you will update the entire Internet (or, on a smaller scale, all the components and legacy applications of an enterprise) all at once. And until you do, you will need your shiny new IPv6-enabled machine to access everything else.
The v6->v4 case is easy enough
No, it isn't (if you do not agree, please feel free to tell me how it is). And please remember that "I'll just put an IPv4 address on it" is not a solution - that will just make it an IPv4 machine as well. And then, why bother adding IPv6 to it??
It would have been possible (simple example: reserve a particular
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?
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. It might even be an incentive for the host's owner to upgrade
You can also access remotely by IPv6, and even access IPv6 websites from an internal IPv4 client that has no support for it.
In the sense you mean, no it wouldn't. v6 and v4 routers don't work the same way.
Can you elaborate on that? The actual routing process is exactly the same, it's just the headers that are different.
That's standard dual stack.
And "standard dual stack" means having two separate networks - one that only speaks IPv4, and one that only speaks IPv6. With no way to communicate between the two. And this is the real issue.
Look a little more into the subject, and you will see that 6to4 does not offer backward compatibility in any way, shape or form. It is simply a way for IPv6 "islands" to communicate over an IPv4 network.
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. And so far, the only mechanism that can do that (at least partly) is a form of NAT - NAT64. And that is still in its infancy, works only one way (v6 client to v4 server), and brings with it all the disadvantages of NAT (which we are trying so hard to avoid by moving to IPv6).
Even though I do not agree with his solution to the problem (I don't think his multicast solution would have solved the problem), the OP (Alomex) is right - there is no backward compatibility built into IPv6. And this is what has hindered IPv6 adoption from the very beginning.
It's a presentation I keep coming back to again and again (every single time somebody asks me "why don't people deploy more IPv6?").
Yes, the font and colors used will make your eyes water (I really wonder if he actually chose them that way on purpose
Absolutely. The air is just one big tube.
However, I wonder if it would be faster to just dump a bunch of carrier pigeons on a truck instead and transfer the data that way?
As opposed to just dumping the memory cards in the truck? (which somehow seems... simpler
"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." - Tanenbaum, Andrew S. (1996)
Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who, "Androids of Tara"