It is probably safe to assume that private networking has been an afterthought. In fact, the Internet Engineering Task Force (IETF) document (RFC 1918) that created private network addresses that are “un-routable” was released years after BGP-4 and IPV6 were codified into standards.
In order to join private networks to each other, wide area networks (WANs) emerged. Initially, the benefits obtained by WANs were just pure connectivity. Subsequent benefits accrued, including the belief that private networks were secure because addresses of servers and clients in the private address could not be reached from the public network unless a “translation” or rule was established. This, however, may no longer be the case.
Here’s a look at WAN deployments through the ages:
The WAN before now
Nearly every use of the Internet is a bi-directional packet flow that originates or terminates in a private network. Early WAN deployments were physical. Wires, pseudo wires, dark fiber, microwave, lasers and other schemes were used to connect buildings and properties. The WAN was truly a single managed network spanning geographic areas. These WANs used routers and switches, yet never shared or connected any information with the public Internet.
Tunnels of all types (GRE, MPLS, IPSEC, etc.) emerged as a way to connect private networks across shared or public network infrastructure. A tunnel has one purpose – to get a packet to go somewhere it wouldn’t go otherwise. People argue a tunnel provides security or privacy, but in fact encryption technology provides this, and tunnels are not a prerequisite to encryption. Tunnels also present aggregated flows to networks breaking network understanding and thus fairness. Tunnels use between 10 and 20 percent additional bandwidth, and frequently cause packet fragmentation issues. Another way of looking at this is the need for a tunnel indicates networking technology is inadequate. The meteoric rise of tunnels in all aspects of networking strongly suggests networking needs to be rebooted.
The WAN of today
Collections of tunnels are called SD-WAN and often referred to as “virtual networks,” since anything that is “virtual” is better, right? A better technical term is “overlay.” These collections of tunnels running over one or more underlay networks are managed and controlled by a single party. There are no networking technologies that can interconnect these collections of tunnels. One interesting capability most WAN 3.0 solutions have is multi-path routing. Allowing routers to pick interfaces for specific applications is not part of a traditional network routing model. The multi-path routing is a primary source of ROI as enterprises are adjusting to the massive movement to cloud based services.
The future of WAN is No-WAN
Due to forces of mobility and cloud, the chances that a client and server are on the same managed WAN are now reduced to as low as 20 percent. WANs between data centers for east-west traffic will make less sense as application servers scatter from two locations to hundreds. What is needed is a way for the underlay to provide authenticated routing from one private network to another, through any number of network boundaries, at any time with optional encryption.
However, putting all these routing advances into a blender, and adding all 25 years of industry protocols and experience, will not level the playing field. To properly secure, balance and route packets, networks need to understand services. Middle boxes like firewalls, DPI devices and load balancers understand services, but routers do not. This needs to change.
The future network will not have tunnels or WANs or tags. The future network will provide secure packet routing from any private network to any private network through any number of IPv4 and IPv6 networks. The existing networks (private and public) will not change physically, but adding intelligence to routers at the edges will transform the internet from millions of separately managed networks connected by NATs to one large multi-network routing system with end-to-end controls.
This article is published as part of the IDG Contributor Network. Want to Join?