IPV6 Myths

Myth #1: IPv6 networking provides service/location separation
Reality: Totally bogus.

A broken protocol stack and a broken reference implementation are among the biggest issues the Internet is facing today. Both require an application to take a service name, translate it into a network address and establish a connection to that address. Burdened with a transport protocol (TCP) that still lives in the dial-up world, the applications simply cannot cope with a service that is available on multiple network locations.

The IPv6 networking protocol could have solved this problem if its architects hadn't limited themselves to the single goal of extending address length. In its current incarnation, IPv6 gives us a longer address and nothing more.

Myth #2: IPv6 will simplify multihoming
Reality: Missed opportunity.

The designers of IPv6 took multihoming seriously and developed a protocol in which a single host can easily acquire multiple IPv6 addresses, even from address spaces belonging to multiple upstream service providers. Unfortunately, they've never tested their theories in real life. Having multiple IPv6 addresses does not help if the upper layers cannot use them efficiently (see previous myth).

Technologies that could support efficient multihoming with IPv6 are already available (SHIM and SCTP, for example) but not widely used because it's easier for everyone to grab a provider-independent (PI) chunk of address space and pollute the global Internet routing tables.

Without an extra layer between the IPv6 addresses and the applications, the multihoming of e-commerce servers in the IPv6 world remains identical to IPv4 multihoming, and providing resilience to smaller client sites actually gets harder because IPv6 does not have Network Address Translation (NAT).

Myth #3: IPv6 will reduce IP routing tables and BGP problems
Reality: Missed opportunity.

The architects of IPv6 envisioned a strictly hierarchical address space in which every service provider would get huge amounts of address space and advertise only a few prefixes into the global routing tables. Unfortunately, they've never considered the high-availability requirements of e-commerce

The Internet Engineering Task Force (IETF) had 15 years to address multihoming issues but failed to do so (see the previous myth). The only solution available to anyone who wants to be somewhat independent of a single service provider is to get a chunk of PI address space, run the border gateway protocol (BGP) and advertise the PI prefix to the global Internet. If anything, the routing tables will grow exponentially with the introduction of IPv6, as everyone will try to get PI address space.

BGP will fare even worse. Not only will the size of the IPv6 global routing table increase, IPv6 BGP tables use more space (and more bandwidth) than the corresponding IPv4 BGP tables. Last but not least, you should also consider what happens in the IPv6 transition period, when the routers will have to carry both IPv4 and IPv6 prefixes for the same set of end-user equipment.

Myth #4: IPv6 has better Quality of Service (QoS)
Reality: Obsolete.

IPv6 packet headers have a flow field designed to identify individual flows, which might be useful on low-speed links. On a decently fast link, you're forced to use class-based QoS (DiffServ) which uses DSCP field in the packet header, as the flow-based QoS (IntServ) does not scale. DSCP field is available in both IPv4 and IPv6 headers.

Myth #5: IPv6 has better security
Reality: Not true.

IPSec might be better integrated in IPv6 headers, but there's nothing you can do with IPv6 IPSec that you cannot do with IPv4 IPSec.

Myth #6: IPv6 is required for mobility
Reality: No longer true.

When IPv6 was designed, IPv4 did not provide any IP mobility features. The lack of IPv6 networking deployment has prompted the development of IPv4 mobility solutions. Today, it's not hard to implement IPv4-based mobility. It is true, however, that the explosive growth of mobile devices requires enormous amounts of address space that cannot be provided with the IPv4 addresses.

Myth #7: Residential IPv6 is less secure because it does not require NAT
Reality: Ignorance.

Some engineers think that the NAT commonly used in residential CPE devices provides extra security owing to obfuscation of actual IP addresses of the hosts behind the CPE device. Enterprise-grade NAT implementations (available, for example, in Cisco IOS) provide security somewhat equivalent to a stateful packet inspection, but consumer-grade NAT available in most CPE devices does not.

Scanning the IPv6 address space looking for vulnerable hosts (a common hacker pastime) is totally useless in the IPv6 networking world. Using the current best practices, each consumer will get the equivalent of a billion's worth of today's Internet's addresses. Even if your workstation sits behind an unprotected CPE, finding it from afar would be quite a feat.

Furthermore, every modern operating system contains basic firewall capabilities (for example, the ability to block unwanted incoming sessions) that to some degree augment the functionality provided by CPE devices.

Last but not least, if residential security becomes an issue, the market will force even the low-cost CPE vendors to implement some basic filters to protect the end users.

Issues in Evovled Packet Core

Evolved Packet Core Issue #1: LTE data services

In mature mobile markets, there has been a 4G technology divide, with WiMAX services aimed predominantly at data service models, and LTE evolving out of current 3G mobile services, whose initial mission was voice. That said, given how strong a technology LTE is for delivering data services, shouldn't it also be focused on data opportunities?

Most operators believe it should be. LTE planners say that it is critical to plan 4G LTE network deployment in terms of data services, which is why EPC planning is so important. If EPC principles are followed, then mobility management and registration are easily linked to IP Multimedia Subsystem (IMS) service control, and LTE voice services can be added as a control layer. The impact of voice traffic on the data plane would then be minimal.

Evolved Packet Core Issue #2: Networking the towers

Since 4G LTE network capacity per cell is 10 times or more the capacity of 3G technology, fully exploiting its benefits probably requires fiber-to-the-tower technology. The question is then about where the fiber should connect. The traditional method is to backhaul fiber to the local central office (CO)

deployments, that would create an aggregation issue in central offices, which would only increases the CO requirement for fiber capacity outward to service points. So is the traditional approach the right one?

Operators have a growing conviction that the metro topology of EPC should create a series of wireless aggregation points to which fiber from the towers is homed. This is most practical in dense metro areas, of course, but as long as utility fiber or right-of-way is available, creating fiber paths from the tower to a node close to the service points for voice and data improves performance and Quality of Service (QoS) control.

Evolved Packet Core Issue #3: Mobile security

The advent of smart mobile devices generates a risk that mobile appliances could be used to attack one another, elements of the infrastructure, or even wireline sites, given higher mobile bandwidth. Mobile services also expose operators to the risk that customer information and location might be revealed and used in illegal activity. The question is whether to push mobile security as an appliance or a network issue.

Operators seem to agree that mobile security is a network issue, but they also recognize that many mobile applications (phone-as-credit-card, for example) demand a high level of handset/appliance security. Operators are looking for a service-based security system for mobile that lives in the network and can be extended via hotspots, femtocells and home services into the wireline space. Virtually all operators see this as a layer beyond EPC and IMS because it is most significant for Internet-based services.

Evolved Packet Core Issue #4: QoS and traffic management

While there is long-standing operator conviction that QoS is a major service differentiator, two emerging trends seem to counter that notion. First, the Internet has conditioned users to best-effort services, reducing the premium they'll pay for QoS. Second, regulators are wrestling with questions of net neutrality that may influence whether operators could charge for premium handling.

Most operators believe that traffic management for mobile networks will be an essential part of providing reasonable service quality to all, but they are concerned whether traffic management applications to provide premium handling will be profitable and acceptable. They are most likely to invest in approaches that are cost-effective in managing traffic at the level needed to assure network stability but are also expanded in scope to supply premium handling where it is legal and profitable. Most believe that EPC tunnel management provides the needed transport facilities but that registration and application security will be needed to link traffic flows with service policies.

Evolved Packet Core Issue #5: App developer programs

The last issue focuses on developer programs and mobile services. Operators have been impressed (and sometimes annoyed) at the success of application stores like the one Apple launched with its iPhone. They are also worried that a highly competitive smartphone and data appliance market may sap their own opportunities to provide premium mobile services. To offer application stores without differentiated applications to sell seems like a waste of an opportunity. But where can differentiation be created?

Most operators believe that exposing some service assets through developer programs and software tool kits is essential, but they are very concerned that exposure could threaten network stability. Operators consider some mechanism to isolate basic EPC processes from developers through a gateway to be essential in protecting service experiences to the user. Operators are working with equipment vendors to create the right model.

Using operator views as a guide

4G LTE network infrastructure planners should use operator consensus as a guideline in their own planning, recognizing that every mobile operator has a unique market and business model, unique regulatory oversight and unique current network infrastructure commitments. The best answers from the industry are only policy guidelines to be used in creating the best answer for your own company.

Evolved Packet Core for 3G/4G

majority of wireless traffic rides traditional wireline copper and fiber facilities for most of its trip from originator to destination. But for the portion of the network that is wireless, data services growth on 3G networks has created a mobile backhaul problem in terms of transporting this traffic to or from the wireline network to the user.

For 4G Long Term Evolution (LTE) services, the new Evolved Packet Core (EPC) gives operators an architectural advantage for transporting wireless traffic. Yet for operators deploying LTE from a 3G service-base, evolving 3G mobile backhaul to EPC may be as big a planning issue as evolving 3G radio networks and handsets to 4G.

Transport infrastructure for 3G and 4G services can be divided into two categories:

1. Mobile service elements with components that are aware of registration, mobility and service control aspects of mobile services;
2. Transport/backhaul elements that provide connectivity between tower locations and service points.

Making sure mobile backhaul accommodates both 3G and 4G services

Both mobile service and transport/backhaul elements must be evolved in harmony so they can transition between 3G and 4G services

Mobile backhaul and 3G transport strategies vary depending on exactly what kind of 3G services are used (e.g., EDGE, HSPA, CDMA). In practice, however, most operators have deployed either time-division multiplexing (TDM) or asynchronous transfer mode (ATM) (AAL2) backhaul facilities to take advantage of their metro infrastructure and core technology.

This backhaul structure must be migrated to EPC during the evolution to 4G, and since fiber-feeding the tower sites is the preferred approach to 4G deployment, either parallel TDM/Ethernet or TDM over Ethernet Pseudowire Emulation Edge-to-Edge) is likely to be deployed.

The question of integrating TDM backhaul for 3G with LTE/4G backhaul, which is also appropriate for High Speed Packet Access (HSPA) creates a question in the Evolved Packet Core's basic topology. EPC architects know that the logical architecture of an EPC connection in the data plane is tower (eNodeB)-to-gateway-to-service. The gateway in this context is the place where mobility registration and service control meet address assignment and data network connectivity.

Evolved Packet Core specifications, however, provide for the separation of the gateway into a serving gateway (SGW) and a packet data network (PDN) gateway, or PGW. This separation creates an EPC sub-network of tunnels where Quality of Service (QoS) and traffic management are more directly under the control of the service control logic (such as IP Multimedia Subsystem (IMS). This capability can be used to provide low-latency transport for TDM being transported over LTE facilities.

3G/4G Evolved Packet Core migration and integration planning

For migration planning, it is convenient to view the mobile service elements of 3G and 4G services by pairing elements roughly according to function. 3G circuit-mode connections used for voice can be simply tunneled or carried as noted above using parallel TDM/ATM or integrated pseudowires over Ethernet or IP. 3G packet traffic handling is where the tightest integration between the mobile service elements and backhaul strategies must be considered.

A good starting point is to consider the ultimate 4G logical model of mobile service elements and how they integrate with the 3G model. The Serving GPRS Support Nodes (SGSN) and Gateway GPRS Support Nodes (GGSN) relationship in 3G corresponds to the "trio" of Mobility Management Entity (MME)/SGW/PGW in LTE's EPC. The question, then, is whether the 3G and 4G elements are interconnected or integrated, which will depend on each operator's 4G architecture.

Mainstream network equipment vendors support three basic models for providing mobile service elements in Evolved Packet Core:

1. Elements can be discrete nodes, with each logical EPC component representing a unique device.
2. Elements can be fixed cards or interfaces on a router/switch device, so that logical EPC components are mapped not to their own devices but to specific packet metro/core elements.
3. Elements can be "logical" and hosted by one of many switch/router or other service components in the network.

For any of these models, 3G and 4G functionality can be provided either independently or hosted in a single device. The latter solution is optimal where there will be considerable 4G deployment, where 3G elements are older (and thus represent less asset displacement cost), and where service evolution to 4G is expected to be rapid.

Where it's not feasible to replace SGSN/GGSN functionality with a dual 3G/4G/EPC node set (MME/SGW/PGW), the only option is to link the 3G elements with the 4G network to combine the traffic. Where integrated fiber backhaul connects tower sites with both 3G and 4G radio access networks (RANs), the use of integrated functionality for 3G/4G elements is much preferred because all traffic will emerge from backhaul at the same point.

Where operators are integrating 4G mobile elements into packet edge devices, it may be difficult or impossible to support both 3G and 4G missions on the same node because of constraints in 3G support by packet edge cards. Because of the flexibility that packet-edge hosting of EPC components offers, it is possible to host EPC components at the edge adjacent to the location of the 3G SGSN/GGSN that must be connected, and thus to reduce handling and latency.

Aiming for flexible Evolved Packet Core deployment

The most flexible approach would be to treat all of the Evolved Packet Core elements (MME, SGW, PGW) as logical entities that can be combined and hosted on available equipment in a variety of ways as network service demands evolve. This could allow operators to align the EPC components with current 3G elements and to create tunnels between 3G and EPC for packet traffic (UMTS Terrestrial Radio Access Network, or TRAN, traffic) where appropriate. As voice, data or all traffic evolves off of the 3G network, the location of the logical functions could be revised by changing the hosting points.

Many mobile operators and planners still think in terms of discrete devices when they think of mobile service elements, but that trend is reversing as operators understand the flexibility and operations benefits of having their packet edge devices host EPC roles. If that hosting is further enhanced by a "logical EPC" capability to permit rapid reconfiguration of the relationship between the EPC and the underlying metro/core network, the result is a structure that adapts not only to the evolution from 3G to 4G, but also to the changes in traffic and services needs that will inevitably come in a mature 4G market.