Subject: Re: [v6ops] IPv4 trajectory

From: "George, Wes" <[email-masked]>
Date: Fri, 3 Apr 2015 09:44:34 -0400

Adding sunset4, since this looks a lot like a discussion about turning off IPv4. :-)

From: Ca By <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 31, 2015 at 11:06 PM
To: "Fred Baker (fred)" <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] IPv4 trajectory

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

> On Mar 31, 2015, at 5:11 PM, Brian E Carpenter <[email-masked]<javascript:;>> wrote:
>
> 5. Therefore, migrate IPv4 support to run over IPv6.

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.
WG] while this is somewhat true, MPLS does depend on IPv4 today, and "quite happy" is probably overselling things. More on that below.

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.

WG] as with most things, ask 10 operators and you'll get 15 answers. I am not sure whether the DFZ part of "DFZ operator" matters in this discussion, but here's my situation (large MSO with a backbone):
On my network, we are properly dual-stack. LDP is enabled because MPLS serves to provide a set of services, mostly L2VPN. Thus IPv4 unicast ends up being label-switched. But we're still running native forwarding for multicast (of which there is quite a lot since it's how we distribute video) and for IPv6.

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.

WG] yes, growth of address usage in the backbone isn't the driver. But I disagree that there's no pressure. There is a non-trivial incremental cost for operations to manage a dual-stack network vs a single-stack one because much of the configuration and troubleshooting is address-family specific even if there are a lot of similarities and reusable bits, and there are a whole raft of hardware/software test cases around keeping IPv4 working that I could eventually jettison if I didn't need IPv4 on parts of my network. But really, the pressure to change the composition of the backbone comes from two things:

 1.  IPv4 GUAs are for customers. While there isn't a lot of IPv4 needed to number the backbone, depending on net customer growth rate and the cost of addresses, the value of reclaiming several blocks of IPv4 addresses from your infrastructure could be significant (does it buy you enough time to avoid that next investment in addresses or CGN?). However, I do think that the backbone will be among the last places that reclamation happens, for reasons I'll detail below.
 2.  RFC1918 is also exhausted, so it's not a viable alternative. I'm deploying large amounts of IPv6-only gear today because I have O(millions) of devices that need addresses for management and internal stuff for which I can either waste GUA, reuse RFC1918 many times and deal with the attendant headaches, or just move it to IPv6.

The problem with this conversation is that we're still treating this as an all-or-nothing exercise, and thus conflating forwarding, control, and management, though each has its own timeline for moving to IPv6-only, and we are also artificially constraining this to some definition of backbone, rather than the overall infrastructure in a given carrier, which is not homogenous and thus also has different timelines for IPv6-only viability. For example: Large carrier WiFi deployments employ APs that are centrally controlled and encapsulate every user packet (IPv4 and IPv6) back to a WiFi core (usually via GRE or L2TP). There's no reason why that network, including the backbone that it rides on, couldn't be IPv6-only from the AP to the core tomorrow assuming the vendor support is there, and the number of devices means that reclaiming the IPv4 addresses in use is attractive. This essentially looks like your step 4.

It's getting easier to consider transitioning the management plane to IPv6-only now that equipment vendors understand that we're serious about doing that, and I think there's value in being able to do it, because as I observed in Opsec yesterday, the ACLs that open up different parts of the management plane for IPv4 are a mess, lots of blocks, lots of holes punched for systems that no longer exist, lots stuff that everyone is afraid to touch for fear of breaking something. IPv6 offers a reset button, where you can explicitly identify what needs to be talking to the network and purge the cruft. It also makes it more obvious when something is broken in IPv6, because your management traffic is running over IPv6, thus customer-impacting issues are less likely to be masked by happy eyeballs. IMO, it's an integral part of the transition from IPv6 as a toy (where it's ok if it breaks) to IPv6 as mission-critical as the primary protocol for your network. If you incrementally enable IPv6 management plane services over time, eventually you reach a point where everything supports IPv6 and you can start pruning IPv4 away.

The challenge for a transit provider with transitioning the backbone to IPv6-only on the control/forwarding planes is that until you have some sort of solution that encapsulates IPv4 to a couple of defined exit points, and still provides access to the full IPv4 routing table, either via route reflectors and multihop, or a direct path, you're still stuck carrying the BGP routes around at least some parts of the network, and I don't think that you'll convince anyone that carrying IPv4 NLRI over an IPv6 BGP session is a good idea given the amount of next-hop headaches we had with trying to do the opposite. Though it may be possible to go IP unnumbered on the WAN links, and keep IPv4 loopbacks for BGP peering, I'm not sure that buys you much by itself. Being able to find a solution that allows you to reduce the number of places that have to carry a full IPv4 routing table does have attractive routing hardware scaling implications, so I do think that this will be something carriers are going to be interested in, even if it's just a modification of the existing lean-core ideas.

As far as MPLS is concerned, once the user-plane traffic is either IPv6 or encapsulated IPv4 and all that remains that requires IPv4 is MPLS-based services, there will be a decision point – do you try to move your MPLS control plane to IPv6, or do you try to replicate those services using IPv6 natively? Neither of those are answerable at the moment, because RFC7439 has a whole punch list of things to fix in MPLS-land so that MPLS is no longer dependent on IPv4, and IPv6 Segment Routing is still pretty far away from being an acceptable alternative to LDP for offering MPLS-like services. Either way, this is something that IETF needs to be working on, so that there are solutions ready before carrier networks get to that decision point. IETF's timescales mean that we need to be out ahead of this even if it seems far-fetched right now.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 3 Apr 2015 17:34:43 +0000

Dumb question. There were at least a couple of comments early in the thread about “we should have an ID that says this”. I hacked one together, basically an updated version of the email.

(1) are we interested enough to actually have a draft, or does it just seem cute?
(2) if we’re interested enough to have a draft, what working group?
(3) if we’re interested enough to have a draft, it seems to me that I should have 1-3 co-authors, from SP, enterprise, and perhaps CDN environments, that can comment with some authority about the process and considerations in their environments. I would want the co-authors to add text as they deem it appropriate.

See attached.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 3 Apr 2015 18:35:56 +0000

HI Fred

Thanks for writing this and it while this type of document  may not seem critical or valuable  to many on this mailing list,  it will be helpful to many of us enterprises who are  currently stuck between 3.2 and 3.3,  without a next step clearly in site.    (and unfortunately,  blissfully content to stay there).  

To understand what the logical transition phases should be and to provide  some relative guidance on implementation choices, will be effective in motivating many of us currently looking for excuses to "Do Nothing" in the IPv6 deployment  space.  

When you said:

"  Many networks continue to kick the tires, lacking a business
   requirement to go to the next step."

This is spot on and really hits  home for many of us enterprises.    We currently have IPv6 on  our clients and servers (mostly because it is easier than trying to figure out how to remove it), on local links only.   We also have IPv6 in labs          But no IPv6  traffic crossing any layer 3  boundaries or being transferred to any meaningful destinations  (production applications, inter-organizational servers,  Internet sites,   etc. ).      

So assistance, advice, guidance, encouragement or however you may categorize this document,  it would  be helpful to those of us currently dealing with our fears of doing something meaningful with IPv6.  	

IMHO,  if this draft moves forward,   V6OPS would appear to be the appropriate WG.   With support from SunsetV4 . 

If you do continue with this draft,  I would be more than willing to assist in any way you deem appropriate.  

So, thanks again for doing this.  

Mike  

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Friday, April 03, 2015 1:35 PM
To: George, Wes
Cc: IPv6 Ops WG; [email-masked]
Subject: Re: [v6ops] IPv4 trajectory

See attached.

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: Xing Li <[email-masked]>
Date: Sun, 05 Apr 2015 17:28:02 +0800

Brian E Carpenter 写道:
> 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.
>   

Just for the information, this is easy for the backbone. CERNET2 
(IPv6-only) is doing this for about 10 years. Of cause, the BOSS is 
another story. xing

> 4. Observe that IPv4 has become secondary.
>
> 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
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>