IPv6?

Another issue that surfaces on a regular basis is the future of the current version of IP, IP version 4. There has been debate over many years as to when, or whether, the Internet should transition to IPv6. My own position on this is skeptical for the following reasons.

Recall that the Internet is a network of networks. The Internet backbone is composed of networks from tier-1 Internet companies such as Verizon, AT&T, Sprint, British Telecom (BT), Deutsche Telekom, and so on. Smaller tier-2 carriers connect to the tier-1 companies, and in their turn offer connectivity to even smaller tier-3 ISPs. All of these networks are currently running IPv4 for Internet traffic. Since a collective cutover to IPv6 is not on the cards, any protocol migration to IPv6 is fraught with practical difficulties. The early mover will encounter guaranteed IPv4-IPv6 interworking issues, will gain few advantages from the move, and will contemplate wistfully the many advantages that would have been gained from sticking with IPv4 for the duration.

When the IETF designers finalized IPv6 back in 1994, they had added to it many attractive features over IPv4. These included support for end-to-end security via IPsec, support for class-of-service marking via a new Differentiated Services field in the IPv6 header, support for host mobility (mobile IP), support for auto-configuration and, of course, the much larger address field. Unfortunately for IPv6, time has whittled away many, if not all, of these advantages. To put it especially bluntly, most everything of value in IPv6 was re-engineered back into IPv4 on the understandable basis that the world couldn’t wait.

§  IPv6’s class-of-service marking scheme replaced IPv4’s obsolete “type of service” header field as the new IPv4 Diffserv Code Point—DSCP.

§  IPsec was engineered to work with IPv4.

§  Mobile IP was engineered to work with IPv4.

§  DHCP configuration of IPv4 hosts obviated most of the IPv6 auto-configuration facilities.

§  Private addressing and NAT resolved the address space problem in practice.

Despite claims that these engineering hacks would impact on usability, the difficulties have been steadily overcome. Even some of the hardest problems, getting signaling applications for VoIP to work through NAT and firewalls, have now been mostly solved. Skype is a case in point, following the earlier pioneering work in network gaming and peer-to-peer file sharing.

There is a purist motivation for IPv6, which looks to get back to a clean and transparent end-to-end Internet model leveraging the larger address space of IPv6. NAT is particularly disliked, seen as breaking the simplicity of host-router transparency. However, with NAT making some contribution to network security and working well in practice, the practical motivation is less strong. Given the lack of a positive business case for the IPv4 to IPv6 transition, together with the effectiveness of the IPv4 “workarounds,” it is hard to predict whether the transition to IPv6 will ever happen. One positive but seldom-mentioned feature of IPv4 against IPv6 is that 128 bit IPv6 addresses such as:

2001:0db8:85a3:08d3:1319:8a2e:0370:7334

are a lot harder for humans to manage than IPv4’s 66.249.64.4—even after the many rules for presentationally shortening IPv6 addresses have been taken into account.

Ethernet Provider Backbone Bridge/Transport (PBB and PBT)

Even MPLS is being challenged. As carriers move to a simplified and more cost-effective technology stack, the prospects of carrying IP within Ethernet directly over the OTN seem increasingly attractive. Traditional Ethernet has scaling and management problems, because its forwarding model depends on Ethernet switches flooding outbound network links with Ethernet frames where the destination is not known, and then learning which exit port to use in future by noting which port the reply eventually arrives at. For this to work, there has to be a unique path between any two points on the network, which is guaranteed by Ethernet’s spanning tree protocol. This turns off network links between Ethernet switches until a minimal covering tree remains, but the procedure has a number of problems including inefficient use of network resources and long recovery times in the event of link or node failure (a new tree has to be recomputed and established).

However, using Provider Backbone Transport, a subrange of VLAN tags is reserved for carrier forwarding purposes, the chosen tags (+ destination addresses) functioning somewhat similarly to MPLS labels. This forwarding information is provisioned into the carrier Ethernet switches by the central network management function, or by GMPLS, to create forwarding virtual circuits (and optionally failover restoration paths) across the carrier network. Unlike the situation with MPLS labels, however, the PBT combination of destination MAC header and VLAN tag is globally unique and identical across network switching elements. This offers significant advantages over MPLS in fault finding and tracing.

Carrier Ethernet is seeing a number of innovations that increase its capabilities, including:

§  MAC-in-MAC—the provision of a separate carrier forwarding address field, pre-pended to the enterprise customer header (defined in 802.1ah, and also called “Provider Backbone Bridge”)

§  Q-in-Q—used to create a hierarchy of VLAN tags allowing carriers to distinguish between customers (defined in 802.1ad, and also called “VLAN stacking”).

With these, Ethernet is now beginning to match MPLS accomplishments, both in traffic engineering and in the provision of customer VPNs. The battle to come will prove interesting.