Re: [v6ops] IPv4 trajectory

["George, Wes" <[e-mail]>]

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

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



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

> On Mar 31, 2015, at 5:11 PM, Brian E Carpenter <[e-mail]<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.