Subject: [v6ops] IPv4 trajectory

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 31 Mar 2015 05:35:48 +0000

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?

---

From: Erik Nygren <[email-masked]>
Date: Tue, 31 Mar 2015 10:02:02 -0400

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

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 31 Mar 2015 15:08:40 +0000

Fred

Thanks so much for this update to the transition steps, as it more accurately depicts what I see in Corporate/Enterprise networks today.  (which is frequently  different than I hear when at IETF).   

I have 3 related comments: 

*  I would separate step 2 into 2a and 2b,  where 2a is  IPv6 existing  in a lab or isolated network only.   2b remains as you described 2.          Many I know are currently caught between 2a and 2b.   
*  Corporate/Enterprise networks  do a lot of Private (internal) to Public (external) IPv4 NATs.   Unfortunately I see this continuing for a long time to come, as it involves issues frequently beyond the control of one enterprise.     Thus 5 may be longer and larger "Little Bits"  than most of us would like.     Perhaps we can think of facilitating transition rationale &  tools to address this?    
*  To get from step 5 to 6, there will be a lot of internal IPv4 addresses that seemingly have NO REASON TO CONVERT to IPv6.    I would like to reverse this thinking in  the manifold corporate networks I hear it from,  but have not come up with anything very convincing   yet.  

  I have not run into LISP yet, so cannot comment on related issues. 

Thanks again for this rendition!

Mike

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Tuesday, March 31, 2015 1:36 AM
To: IPv6 Ops WG
Subject: [v6ops] IPv4 trajectory

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

1) IPv4-only network

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Mar 2015 16:15:17 +0000

Hi Fred,

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

Please also list AERO. It supports IPvx-in-IPvy tunneling with mobility management,
and is very simple:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

Thanks - Fred
[email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 31 Mar 2015 18:12:08 +0000

> On Mar 31, 2015, at 8:08 AM, Ackermann, Michael <[email-masked]> wrote:
> 

To be perfectly honest, I don’t expect those to ever convert. Sooner or later, their equipment will be replaced, and when it is, the person installing it will be faced with the question of what communication technology to use. I expect those choices to be what makes the step.

The comment about “and along with it, biSync and X.25” was not an idle one. We’re still waiting for the last bisync terminal to die, and X.25 has a constituency in the telephone world.

The other thing I notice, though, is that we don’t have people jumping through hoops to keep those things going. As long as they cause less trouble than they contribute value, value wins. The day the value gasps for breath, so will they.

I’m not even especially concerned about getting from step 4 to step 5. I suspect that economics will get applications to the native network; the only question is “when”. If A works better than B and is less cost to maintain, A will eventually win out.

My only real concern is getting from some variant of step 2b or 3 to 4. At least in part, my reason for describing “step 4” experiences is to point out that there are those who are going there, and to provide “no BS” analyses of that.