Design Article
Comment
Bench
Use best practices to deploy IPv6 over broadband access
Tara Van Unen
6/20/2011 9:11 AM EDT
After more than a decade of forewarning, the IPv4 to IPv6 transition has finally reached critical mass. On Feb 1, 2011, the AINA allocated the last freely available block of IPv6 addresses. At the same time, the number of users and "endpoints" requiring Internet access - and thus a unique IP address--continues to explode. With exponential growth in global broadband deployments, next-gen wireless rollouts on the horizon, and fast-growing smart phones in the field, the industry is predicting an increase of 5 billion unique endpoints by 2015. In the meantime, service providers are struggling to prepare their networks for the influx of IPv6 addresses.
While the Internet is rich with IPv6 content and services- Google is already supporting IPv6 on its search, news, docs, maps and YouTube- IPv4 won't just "go away" as IPv6 comes on board. This creates a challenging situation for service providers that must upgrade their network infrastructure to handle IPv4 and IPv6 co-existence.
Network cores are well equipped for handling both IPv4 and IPv6, however broadband access networks are not. IPv4 and IPv6 co-existence puts tremendous stress on the underlying network systems, which can potentially introduce latency, degrade network responsiveness, and compromise service level agreements. The biggest transition concern is the impact on customers: will introducing IPv6 endpoints, forwarding tables, and services affect connectivity speed, service quality, and network reliability?
IPv6 Solutions for Broadband Access
An abrupt transition of the legacy IPv4 infrastructure to IPv6 is not practical because most Internet services are still based on IPv4 and many customers are still running operating systems that do not fully support IPv6. Service providers must support both IPv4 and IPv6 endpoints and service in order to guarantee the quality of service (QoS) defined in their service level agreements (SLA).
There are different methods that can be used to achieve this goal across broadband access networks including:
* Translation
* Tunneling
* Dual-Stack Network
Translation
The easiest way to conserve the depleting IPv4 address space is to use translation so that the outward facing interface uses a public interface while the private network uses IP addresses that are not routed on the Internet. However, the known performance and scalability issues compel most service providers to deploy either tunneling or dual-stack transition mechanisms in broadband access networks.
Tunneling
Tunneling mechanisms are used to tunnel IPv6 islands' traffic over IPv4 networks and vice versa. The two tunneling schemes currently receiving significant industry attention are:
* Dual-Stack Lite
* IPv6 Rapid Deployment
Dual-Stack Lite
A DS-Lite device is provisioned with both an IPv4 and an IPv6 address on its interface(s). DS-Lite uses IPv6-only links between the provider and the customer. When a device in the customer network sends an IPv4 packet to an external destination, the IPv4 packet is encapsulated in an IPv6 packet for transport into the provider network. There is no network address translation (NAT) service on the customer premise equipment (CPE) device, such as home gateway.
If a home device needs to access an IPv6 service, it is transported "as is," and routed to an Internet server. The IPv6 tunnel source address is added to the NAT table along with IPv4 source address and port to both disambiguate the customer private address and provide the reference for the tunnel endpoint. With DS-Lite technology, the communications between end nodes stays within their address family without requiring protocol family translation.
How DS-Lite Works
There are multiple advantages of DS-Lite over using a cascade of NAT's:
* Tunnelling IPv4 over IPv6 is far simpler than translation so it performs much better than NAT464.
* The deployment of IPv6 in the service provider network is decoupled and independent of the customers migrating to IPv6. If customer equipment is IPv6 aware, the packets simply follow the IPv6 routing to reach the destination, and no tunnelling is performed.
* Increased traffic load can he handled by adding more AFTR elements in the service provider network. It provides flexibility to adapt to changing traffic load.
IPv6 Rapid Deployment (6rd)
6rd relies on IPv4 and is designed to deliver production-quality IPv6 alongside IPv4 with as little change to IPv4 networking and operation as possible.
A 6rd domain consists of:
* 6rd Customer Edge (CE) routers, also refer as Residential Gateways (RGs) or Customer Premise Equipment (CPE). A 6rd CE functions as a customer edge in a 6rd deployment and is the initiator of the 6rd tunnel
* One or more 6rd Border Relays (BRs). A 6rd-enabled router is managed by the service provider at the edge of a 6rd domain. The BR terminates the IPv4 tunnel and transmits native IPv6 outside the SP network.
The 6rd mechanism relies on an algorithmic mapping between the IPv6 addresses and IPv4 addresses that are assigned for use within the service provider network. An IPv6 prefix, called a "6rd prefix," is selected by the service provider for use by a 6rd domain. The IPv6 packet is encapsulated inside IPv4 by an 6rd CE and follows the IPv4 routing topology within the service provider network among CEs and BRs.
Dual-Stack PPP
Many service providers are planning to deploy dual-stack networks as a long-term strategy, supporting a mixture of IPv4 and IPv6 applications for customers that require both protocols. Dual-stack-capable devices support both IPv4 and IPv6, from the network layer to the applications. Applications choose between using IPv4 or IPv6, with the application selecting the correct address based on the type of IP traffic and particular requirements of the communication. Dual-stack deployments are more cost- and time-intensive to deploy than tunneling technologies, since all devices in the network require a software upgrade(at minimum) to support both IPv4 and IPv6 protocol stacks.
Dual-stack PPP resolves IPv4/IPv6 compatibility issues and facilitates transition to IPv6 by enabling IPv6/IPv4 nodes to send and receive both IPv4 and IPv6 packets. Each individual PPP session results in getting both IPv4 address and an IPv6 prefix that can be used to assign addresses to IP devices at the customer site.
Dual-stack PPP over L2TP is a specialized case of Dual-stack PPP, wherein the L2TP access controller (LAC) and L2TP network server (LNS) are tunneling Dual-stack PPP sessions. The result for the end user is still an IPv6 address, but in Dual-stack PPP over L2TP replicates PPP over an L2TP network.
Dual-stack PPP supports the use of DHCPv6 to get broadband subscribers their IPv6 addressing and other networking configuration information directly from the provider edge (PE).
Test Requirements
For DS-Lite and 6rd, it is important to measure the functionality and performance of tunneling mechanisms on network equipment prior to deployment. To offer customer a seamless IPv6 transition, service providers must ensure services can be delivered with requisite quality guarantees. Network design and configuration requires protocol and traffic stress testing to identify the scalability limits of each device.
It is equally important to validate interoperability of the different network devices, especially given the compatibility risks between IPv4 and IPv6 technology. Test equipment plays a critical role in this validation as it enables reliable, repeatable measurements across network devices.
Test equipment can validate key measurements for device functionality, forwarding performance, and application performance, allowing comparative analysis between different network hardware and tunneling implementations (i.e., DS-Lite vs. 6rd).
Below is a quick summary of key DS-Lite and 6rd test requirements.
For Dual-stack network deployments, supporting and scaling both and IPv6 and IPv4 versions of each protocol can be process-intensive for infrastructure equipment. It is imperative to verify that the device under test (DUT) can successfully complete the protocol negotiati ons, setup sessions at a high rate, and scale clients and traffic.
Test equipment is used to emulate clients and servers surrounding the Dual-Stack DUT. Test equipment must be able to:
* Simulate different clients types
* Emulate both IPv4 and IPv6 protocol stacks
* Generate both IPv4 and IPv6 traffic
* Test a variety of device types (BNG s, DHCPv6PD, BRAS, LAC, LNS, etc.)
Below is a quick summary of key Dual-stack test requirements:
Conclusion
With IPv4 address depletion, IPv6 applications and endpoints will soon become ubiquitous across end-to-end networks. 2011 will be a year of significant access network upgrades to support IPv6 and the dual-stack technologies required for IPv6 services. To ensure this evolution is transparent to subscribers, network equipment vendors and service providers must demonstrate that network equipment is ready for IPv4/IPv6 co-existence.
Pre-deployment testing will play a critical role in mitigating any risk to service reliability, scalability, and quality. Comparative metrics between network equipment will also enable service providers to maximize their investment in new and upgraded infrastructure, and best optimize network configurations.
About the Author
Tara Van Unen is a Sr. Manager, Market Development for Ixia. She specializes in developing Ixia's strategic marketing plans for routing, switching and broadband technologies.
While the Internet is rich with IPv6 content and services- Google is already supporting IPv6 on its search, news, docs, maps and YouTube- IPv4 won't just "go away" as IPv6 comes on board. This creates a challenging situation for service providers that must upgrade their network infrastructure to handle IPv4 and IPv6 co-existence.
Network cores are well equipped for handling both IPv4 and IPv6, however broadband access networks are not. IPv4 and IPv6 co-existence puts tremendous stress on the underlying network systems, which can potentially introduce latency, degrade network responsiveness, and compromise service level agreements. The biggest transition concern is the impact on customers: will introducing IPv6 endpoints, forwarding tables, and services affect connectivity speed, service quality, and network reliability?
IPv6 Solutions for Broadband Access
An abrupt transition of the legacy IPv4 infrastructure to IPv6 is not practical because most Internet services are still based on IPv4 and many customers are still running operating systems that do not fully support IPv6. Service providers must support both IPv4 and IPv6 endpoints and service in order to guarantee the quality of service (QoS) defined in their service level agreements (SLA).
There are different methods that can be used to achieve this goal across broadband access networks including:
* Translation
* Tunneling
* Dual-Stack Network
Translation
The easiest way to conserve the depleting IPv4 address space is to use translation so that the outward facing interface uses a public interface while the private network uses IP addresses that are not routed on the Internet. However, the known performance and scalability issues compel most service providers to deploy either tunneling or dual-stack transition mechanisms in broadband access networks.
Tunneling
Tunneling mechanisms are used to tunnel IPv6 islands' traffic over IPv4 networks and vice versa. The two tunneling schemes currently receiving significant industry attention are:
* Dual-Stack Lite
* IPv6 Rapid Deployment
Dual-Stack Lite
A DS-Lite device is provisioned with both an IPv4 and an IPv6 address on its interface(s). DS-Lite uses IPv6-only links between the provider and the customer. When a device in the customer network sends an IPv4 packet to an external destination, the IPv4 packet is encapsulated in an IPv6 packet for transport into the provider network. There is no network address translation (NAT) service on the customer premise equipment (CPE) device, such as home gateway.
If a home device needs to access an IPv6 service, it is transported "as is," and routed to an Internet server. The IPv6 tunnel source address is added to the NAT table along with IPv4 source address and port to both disambiguate the customer private address and provide the reference for the tunnel endpoint. With DS-Lite technology, the communications between end nodes stays within their address family without requiring protocol family translation.
How DS-Lite Works
There are multiple advantages of DS-Lite over using a cascade of NAT's:
* Tunnelling IPv4 over IPv6 is far simpler than translation so it performs much better than NAT464.
* The deployment of IPv6 in the service provider network is decoupled and independent of the customers migrating to IPv6. If customer equipment is IPv6 aware, the packets simply follow the IPv6 routing to reach the destination, and no tunnelling is performed.
* Increased traffic load can he handled by adding more AFTR elements in the service provider network. It provides flexibility to adapt to changing traffic load.
IPv6 Rapid Deployment (6rd)
6rd relies on IPv4 and is designed to deliver production-quality IPv6 alongside IPv4 with as little change to IPv4 networking and operation as possible.
A 6rd domain consists of:
* 6rd Customer Edge (CE) routers, also refer as Residential Gateways (RGs) or Customer Premise Equipment (CPE). A 6rd CE functions as a customer edge in a 6rd deployment and is the initiator of the 6rd tunnel
* One or more 6rd Border Relays (BRs). A 6rd-enabled router is managed by the service provider at the edge of a 6rd domain. The BR terminates the IPv4 tunnel and transmits native IPv6 outside the SP network.
The 6rd mechanism relies on an algorithmic mapping between the IPv6 addresses and IPv4 addresses that are assigned for use within the service provider network. An IPv6 prefix, called a "6rd prefix," is selected by the service provider for use by a 6rd domain. The IPv6 packet is encapsulated inside IPv4 by an 6rd CE and follows the IPv4 routing topology within the service provider network among CEs and BRs.
Dual-Stack PPP
Many service providers are planning to deploy dual-stack networks as a long-term strategy, supporting a mixture of IPv4 and IPv6 applications for customers that require both protocols. Dual-stack-capable devices support both IPv4 and IPv6, from the network layer to the applications. Applications choose between using IPv4 or IPv6, with the application selecting the correct address based on the type of IP traffic and particular requirements of the communication. Dual-stack deployments are more cost- and time-intensive to deploy than tunneling technologies, since all devices in the network require a software upgrade(at minimum) to support both IPv4 and IPv6 protocol stacks.
Dual-stack PPP resolves IPv4/IPv6 compatibility issues and facilitates transition to IPv6 by enabling IPv6/IPv4 nodes to send and receive both IPv4 and IPv6 packets. Each individual PPP session results in getting both IPv4 address and an IPv6 prefix that can be used to assign addresses to IP devices at the customer site.
Dual-stack PPP over L2TP is a specialized case of Dual-stack PPP, wherein the L2TP access controller (LAC) and L2TP network server (LNS) are tunneling Dual-stack PPP sessions. The result for the end user is still an IPv6 address, but in Dual-stack PPP over L2TP replicates PPP over an L2TP network.
Dual-stack PPP supports the use of DHCPv6 to get broadband subscribers their IPv6 addressing and other networking configuration information directly from the provider edge (PE).
Test Requirements
For DS-Lite and 6rd, it is important to measure the functionality and performance of tunneling mechanisms on network equipment prior to deployment. To offer customer a seamless IPv6 transition, service providers must ensure services can be delivered with requisite quality guarantees. Network design and configuration requires protocol and traffic stress testing to identify the scalability limits of each device.
It is equally important to validate interoperability of the different network devices, especially given the compatibility risks between IPv4 and IPv6 technology. Test equipment plays a critical role in this validation as it enables reliable, repeatable measurements across network devices.
Test equipment can validate key measurements for device functionality, forwarding performance, and application performance, allowing comparative analysis between different network hardware and tunneling implementations (i.e., DS-Lite vs. 6rd).
Below is a quick summary of key DS-Lite and 6rd test requirements.
For Dual-stack network deployments, supporting and scaling both and IPv6 and IPv4 versions of each protocol can be process-intensive for infrastructure equipment. It is imperative to verify that the device under test (DUT) can successfully complete the protocol negotiati ons, setup sessions at a high rate, and scale clients and traffic.
Test equipment is used to emulate clients and servers surrounding the Dual-Stack DUT. Test equipment must be able to:
* Simulate different clients types
* Emulate both IPv4 and IPv6 protocol stacks
* Generate both IPv4 and IPv6 traffic
* Test a variety of device types (BNG s, DHCPv6PD, BRAS, LAC, LNS, etc.)
Below is a quick summary of key Dual-stack test requirements:
Conclusion
With IPv4 address depletion, IPv6 applications and endpoints will soon become ubiquitous across end-to-end networks. 2011 will be a year of significant access network upgrades to support IPv6 and the dual-stack technologies required for IPv6 services. To ensure this evolution is transparent to subscribers, network equipment vendors and service providers must demonstrate that network equipment is ready for IPv4/IPv6 co-existence.
Pre-deployment testing will play a critical role in mitigating any risk to service reliability, scalability, and quality. Comparative metrics between network equipment will also enable service providers to maximize their investment in new and upgraded infrastructure, and best optimize network configurations.
About the Author
Tara Van Unen is a Sr. Manager, Market Development for Ixia. She specializes in developing Ixia's strategic marketing plans for routing, switching and broadband technologies.
|
|
|
|
|
Navigate to related information
Bench
6/28/2011 3:58 AM EDT
major typo here:
"On Feb 1, 2011, the AINA allocated the last freely available block of IPv6 addresses."
should be IPv4
Sign in to Reply