Subject: Re: [v6ops] IPv4 trajectory

From: Lee Howard <[email-masked]>
Date: Tue, 31 Mar 2015 09:49:41 -0400

On 3/31/15, 1:35 AM, "Fred Baker (fred)" <[email-masked]> wrote:

>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

Exactly. Note that networks do not move monotonically. That is, for an
eyeball or mobile network, their work may be complete when only 30% of
users have IPv6, and they have to wait for IPv6-incapable user equipment
to age out. That could be step 2, or step 3, or even a messy combination
in which:
a. Some users have native IPv4-only
b. Some users have native dual-stack
c. Some users have native IPv6 with IPv4 and an overlay
d. In cases where 6rd (mostly) was used, some users have native IPv4, with
IPv6 as an overlay

Those may all exist in a single 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.

Fewer and fewer networks will be doing step 3. If they aren't close to
rolling out, they simply won't have the IPv4 address space to do native
dual-stack. I think we will start seeing networks skipping steps.  But
again, these will co-exist; existing customers or installations will
probably remain IPv4-only, with new devices being enabled with IPv6, with
IPv4 as a service. The rest will be transition by attrition.

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

We would also learn something if we get no deployment reports for certain
technologies.

>
>Is anyone¹s head exploding yet?

I was wondering what that sound was.

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Apr 2015 08:10:45 +1300

...

...
> dual-stack. 

Clearly this is true. The original dual-stack model assumed that everybody
would be able to deploy IPng before IPv4 exhaustion.

However, I also wonder whether the transit and core operators, who carry
globally-addressed IPv4 traffic around for other networks, will eventually
move away from pure ships-in-the-night dual stack operation. For example,
will they eventually find it inconvenient to use IPv4 for "control plane"
purposes, and so use IPv6 for all network management? In that case they
will also be operating IPv4 only as a service.

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 31 Mar 2015 23:46:02 +0000

> On Mar 31, 2015, at 12:10 PM, Brian E Carpenter <[email-masked]> wrote:
> 

That’s a question you would have to ask them. I don’t know.

But I’m not sure you’re using the same definition I am for IPv4 as a service. If I understand your penultimate sentences, in a network that carries multiple data types (I don’t know, Netware, CLNS, IPv4, IPv6, whatever) and uses exactly one of them to manage the network, the one is fundamental and the others are “a service”.

The definition I’m using is in the data plane. Does the network carry IPv4 as IPv4, or IPv4 as some variation on IPv6? If it carries IPv4 translated to or encapsulated in IPv6, IPv4 is (according to me) a service.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 31 Mar 2015 23:46:44 +0000

The definition I’m using is in the data plane.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Apr 2015 13:11:37 +1300

> The definition I’m using is in the data plane. Does the network carry IPv4 as IPv4, or IPv4 as some variation on IPv6? If it carries IPv4 translated to or encapsulated in IPv6, IPv4 is (according t…

In fact, I agree. So the sequence I'm thinking of for a transit
or DFZ carrier is something like this:

1. (now) Run dual stack with ships-in-the-night routing, but
   configuration and management is via IPv4.

2. (soon) Ditto, but some config & management moves to IPv6.

3. Ditto, but all config & management is via IPv6.

4. Observe that IPv4 has become secondary.

5. Therefore, migrate IPv4 support to run over IPv6.

This is different (and simpler) than subscriber-facing carriers,
because they will have to navigate all kinds of other issues
like CGN and MAP on the client side.

I'm not saying this is profound; just that it is a different
trajectory from the ones we mainly discuss.

   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 1 Apr 2015 00:32:48 +0000

> On Mar 31, 2015, at 5:11 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Again, if you want the carrier’s logic, ask the carrier. But to me, that doesn’t follow.

Not all core carriers, but a significant number of them, don’t think of themselves as carrying IPv4 or IPv6 per se. They think of themselves as MPLS houses, using jumboframes so that the addition of that header to whatever their payload happens to be (aka IPv4 or IPv6) doesn’t have an MTU problem. Whatever comes in, they throw it into the right tunnel (aka LSP) to get it to the right egress, MPLS gets it there, and it goes out the other door.

You’re arguing about what kind of tunnel they should use. They’re quite happy with the one they have, and it’s neither IPv4 nor IPv6.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Apr 2015 14:12:46 +1300

> You’re arguing about what kind of tunnel they should use. They’re quite happy with the one they have, and it’s neither IPv4 nor IPv6.

Makes sense. But in that case, ships-in-the-night is the final state
for such providers, as far as IPv4 goes; I have no problem with that.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Tue, 31 Mar 2015 20:01:17 -0700

> for such providers, as far as IPv4 goes; I have no problem with that.

they do ships in the night for ipv4.

the p-router portion of the network is protocol agnostic with repect to
encapsulated data, modula practical problems like figuring out how to
make it hash across trunks.

>     Brian
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ca By <[email-masked]>
Date: Tue, 31 Mar 2015 20:06:07 -0700

On Tuesday, March 31, 2015, Fred Baker (fred) <[email-masked]> wrote:

>
> > On Mar 31, 2015, at 5:11 PM, Brian E Carpenter <
> [email-masked] <javascript:;>> wrote:
> >
> Not all core carriers, but a significant number of them, don’t think of
> themselves as carrying IPv4 or IPv6 per se. They think of themselves as
> MPLS houses, using jumboframes so that the addition of that header to
> whatever their payload happens to be (aka IPv4 or IPv6) doesn’t have an MTU
> problem. Whatever comes in, they throw it into the right tunnel (aka LSP)
> to get it to the right egress, MPLS gets it there, and it goes out the
> other door.
>
> You’re arguing about what kind of tunnel they should use. They’re quite
> happy with the one they have, and it’s neither IPv4 nor IPv6.
>

I am not a dfz network operator, but my network has an ipv4 control plane
that is rfc 1918 and only visible to the control plane, for the most
part.  My guess is that most dfz providers are not properly dual-stack,
they are using 6pe or 6vpe.

The forwaring plane is mpls. Full stop.

There is no pressure to ever change the composition of the backbone since
the backbone itself is not scaling quickly in terms of ip address usage.

It is only the edges that scale and sees address pressure: eyeballs, sensor
/ things , cdn, compute ....

So there is no forcing function turning ipv4 off...

Except percentage of 'high value' ipv4 traffic will go down, but dfz routes
will go up. So, this will create an interesting conflict as dfz ipv4 routes
go up, costs go up to support + 1m routes, ddos junk traffic goes up
...ultimately in 5 years the ipv4 dfz will be mostly ddos related udp with
1m+ routes while the ipv6 dfz relatively well aggregated and ddos free (no
win xp, no super legacy cpe, ...)

Knocking on wood the ipv6 stays as clean as it is today.  But, the rate of
decay of 'high value' ipv4 traffic is extreme. Watch this space.  IPv4 is
becoming worse than the back row on $airline

CB