Re: [v6ops] IPv4 trajectory

["Ackermann, Michael" <[e-mail]>]

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:[e-mail]] On Behalf Of Fred Baker (fred)
Sent: Tuesday, March 31, 2015 1:36 AM
To: IPv6 Ops WG
Subject: [v6ops] IPv4 trajectory

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?


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.