Re: [v6ops] IPv4 trajectory

[Erik Nygren <[e-mail]>]

On Tue, Mar 31, 2015 at 1:35 AM, Fred Baker (fred) <[e-mail]> wrote:
> Let me give you my thought process. Happy to be told I am wrong.

Thank you for writing this up!  It makes total sense to me.  I wonder if it
would be useful to turn an expanded version of this into a draft,
especially as this story is one that will be helpful to explain more
broadly?

> Now, what assumptions am I making? I believe that an IPv4 packet can make
it end to end until step 5

The primary exception to this is NAT44 environments where the only IPv4
exists in (overlapping) private address space bubbles.
This has been the norm rather than the exception for a long time now in
many enterprise networks, and with an acceleration of step 4 it may become
even more common.  Perhaps the revised version would be "IPv4 packet can
make it end to end to globally routable services until step 5, but many
hosts require the assistance of services such as STUN to reach each other
directly."

       Erik



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?
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>