Re: [v6ops] IPv4 trajectory

[Brian E Carpenter <[e-mail]>]

On 01/04/2015 12:46, Fred Baker (fred) wrote:
> 
>> On Mar 31, 2015, at 12:10 PM, Brian E Carpenter <[e-mail]> wrote:
>>
>> 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.
> 
> 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.

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