[v6ops] IPv4 trajectory

["Fred Baker (fred)" <[e-mail]>]

In the course of the Google Doc “towards IPv4 as a service” discussion, Brian Carpenter wrote

> Scope question: do we need to distinguish edge networks from Tier 3 provider networks? Are we making the assumption that transit and core carriers remain dual-stack? Listing LISP suggests that we might not be making that assumption exactly.

Let me give you my thought process. Happy to be told I am wrong.

As I read RFC 4213, the transition process was envisioned as taking three steps:

1) IPv4-only
2) IPv4+IPv6 Dual Stack
3) IPv6-only

Had the transition started five or ten years ago, that might have been reasonable. Where things stand, though, I don’t think it is. From my perspective, the process over some amount of time into the future (amount of time is anybody’s guess) will take six steps:

1) IPv4-only network
2) IPv4 with bits of IPv6 here and there, in some combination of overlay and native
3) IPv4+IPv6 (native) dual stack network
4) IPv6+IPv4 non-native, translated or overlay (e.g., as a service)
5) IPv6 with little bits of IPv4 here and there; your printer might be an example
6) IPv6-only

In steps 1 and 2, it is an IPv4 network, possibly with some toys in it playing IPv6. We might have toys playing AppleTalk and DECNet too. IPv4 is the workhorse, and toys is toys.

In step 3, every host in the network has an IPv4 address and an IPv6 address, or constructively could have if it wants one, and every router is carrying IPv4 routing as well as IPv6 routing. It’s likely multiplexing IPv4 addresses, and IPv4 is increasingly broken. But the big question is what applications and providers support IPv6; as long as a big one (Skype?) is not making the transition, people have a business reason to keep IPv4 going. As applications become dual stack, traffic levels approach a 50/50 distribution, barring some specific reason they would be forced to IPv4 or IPv6.

Right now, most networks are still in step 1, and those that have a clue are somewhere between step 2 and step 3. But some are moving, or at least experimenting, with step 4.

steps 4-6 are fundamentally about an IPv6 network.

In step 4, the network is optimizing configurations and costs by making IPv4 a translation or an overlay, but IPv4 remains an important aspect of the network. Obvious examples include anything listed. IPv4 might reach the host one way or another, or be translated some distance away, but a client using IPv4 can reach an IPv4-only server, and it can reply, and part of the path in between is IPv6-only.

In step 5, IPv4 has taken a place comparable to AppleTalk; yes, there’s some there, but where, precisely? And in step 6, we have finally turned IPv4 off entirely, and with it probably Bisync and X.25.


Now, what assumptions am I making? I believe that an IPv4 packet can make it end to end until step 5; it might spend part of that as a translated IPv6 packet or in a tunnel of some kind, but it can get there. As of step 5, that is no longer the case. Exactly how that happens is Not My Department. Note that many core networks don’t describe themselves as IPv4, IPv6, or dual stack networks; they describe themselves as MPLS networks that carry IP as a payload.


Listing LISP... to me, LISP is yet another encapsulation, a tunnel broker, and one that is particularly complex. It can carry IPv6 across an IPv4 network or IPv4 over an IPv6 network. Someone suggested it should be on the list, and it’s on the list. One thing I actually expect is that the list of technologies we might invite deployment reports regarding is longer than the list of technologies people actually use. We might learn something from that.


Is anyone’s head exploding yet?