Nope. For all the reasons I explained to you previously, chief being the fact that IPv6 is 100% incompatible with IPv4 on the wire.

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?!).

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!

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 :) ).

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.

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.

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...

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.

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.

And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".

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.

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)?

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.

No it doesn't. And it cannot. There still is a routing table, it's just... bigger :) (not that big as you would expect though, due to the larger subnets and better aggregation. In theory, at least).

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).

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"?

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".

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?

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).

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.

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 /96 prefix in IPv6 to encompass the "legacy" IPv4 address space). Yes, there is more to it than that (you would need gateways capable of "translating" between that prefix and IPv4), but that is one idea.

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?

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 :) . But that case will only come into play many years later, when we actually have an IPv6-only internet.

How?

Can you elaborate on that? The actual routing process is exactly the same, it's just the headers that are different.

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.

It's not quite what you are suggesting. While I admit I never heard of RFC 5747 before, it seems to discuss a way for IPv4-only islands to communicate over an IPv6-only backbone (something like 6to4 in reverse). Which means it doesn't help with backward compatibility in any way (just like 6to4 doesn't).

Let's see: one person points (very accurately) one of the main reasons why IPv6 isn't widely deployed at the moment: lack of any kind of backward compatibility with IPv4. He gets modded "0, redundant". Another person mentions 6to4, and gets modded "5, insightful". Looks like the mods have been listening to way too much IPv6 marketing, and are starting to believe it.

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.

I'm surprised nobody has posted this yet:

http://meetings.ripe.net/ripe-55/presentations/bush-ipv6-transition.pdf

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 :) ). But the actual content is just as accurate now as it was in 2007, and it comes from someone who actually has quite a bit of experience working with this stuff...

By your standards, bread is the same density as dough, and swiss cheese the same density as... regular cheese :) Face it - sometimes the holes in the structure of the material are relevant, and will affect the overall density (and the fact that they are uniformly distributed is relevant, which excludes your tent). Even ice has a lower density than water because of "tiny holes" in its structures (actually, these "holes" are increased spaces between the atoms making up the ice).

Is it just me, or is the article linked to in the summary ( http://www.arabist.net/blog/2011/1/28/urgent-egypt-has-shut-off-the-internet.html ) no longer online?

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)

CEF (Cisco Express Forwarding) and MPLS [wikipedia.org] (Multiprotocol Label Switching) use flow control. The perform a lookup on the first packet, cache the information in a forwarding table and all further packets which are part of the same flow are switched, not routed, at effectively wire speeds.

It's more than that. The older techologies ("fast switching" in the Cisco world) used to do this - route first packet, then switch the other packets in the flow. However, CEF goes one step forward, and allows for all the packets to be switched by the hardware (not even the first packet in the flow hits the router processor). Which means that what the author seems to be suggesting would actually mean moving backwards.
Either there is more to the router than the article says, or the author hasn't been keeping track of developments in this field...