Home > Articles > Cisco Network Technology > IP Communications/VoIP > Deploying IPv6 in WAN/Branch Networks

Deploying IPv6 in WAN/Branch Networks

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Apr 13, 2011.

Chapter Description

This chapter provides and overview of WAN/branch deployment and also covers WAN/branch IPv6 deployment considerations, WAN/branch deployment over native IPv6, and includes an example of WAN/branch implementation.

General WAN/Branch IPv6 Deployment Considerations

Some general considerations apply to the deployment profiles described in this chapter. The following sections describe the general considerations to take into account when deploying IPv6 in a branch network, regardless of the deployment profile being used. If a specific consideration should be understood, the specific profile is called out, along with the consideration for that profile.

The branch IPv6 profiles described in this chapter leverage the existing Cisco branch network design best practices as the foundation for all aspects of the deployment. The IPv6 components of the profiles are deployed in the same way as IPv4 whenever possible.

It is critical to understand the Cisco branch design best practice recommendations before deploying IPv6 in the branch profiles described in this chapter. The Cisco branch design best practice documents can be found under the "Branch Office" and "WAN" sections at http://www.cisco.com/en/US/netsol/ns816/networking_solutions_program_home.html.


In most cases, the use of a /64 prefix on point-to-point (P2P) links is just fine. IPv6 was designed to have a large address space, and even with the poor address management in place, the customer should not experience address constraints.

Some network administrators think that a /64 prefix for P2P links is a waste of address space. There has been quite a bit of discussion within the IPv6 community about the practice of using longer prefixes for P2P links. For those network administrators who want to more tightly control the address space, it is safe to use a /126 prefix on P2P links in much the same way as /30 is used with IPv4. A /127 prefix can be used if you are aware of the potential address overlap with special use addresses. IPv6 address considerations can be found in RFC 5375 at http://www.ietf.org/rfc/rfc5375.txt.

The P2P configurations shown in this chapter use a /64 prefix. The assignment of end-host IPv6 addresses is done either by using Stateless Address Autoconfiguration (SLAAC) (see RFC 4862, "IPv6 Stateless Address Autoconfiguration"), which advertises an IPv6 prefix (through an RA) on the router subinterface for the VLAN where PCs are located, or through stateful DHCPv6. The options for Domain Name System (DNS) server and domain name are assigned using stateless DHCPv6 or stateful DHCPv6. The configurations for the SLAAC, stateless, and stateful DHCPv6 will be shown later in the chapter.

More information can be found on IPv6 addressing services at the following URL: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/15_0/ipv6_15_0_book.html.

Physical Connectivity

Considerations for physical connectivity with IPv6 are the same as with IPv4, plus five additional elements:

  • Sufficient bandwidth: One important factor for deployment of any new technology, protocol, or application is to ensure that there is a sufficient amount of bandwidth for both existing and new traffic. This issue is especially true with the branch because, in many cases, the connections to the WAN are low-speed links and the reliance on QoS to solve bandwidth problems goes only so far. Bandwidth requirements for IPv6 are outside the scope of this chapter because there are many variables to account for and should therefore be considered on a case-by-case basis.
  • Maximum transmission unit (MTU) and fragmentation: The minimum MTU size for IPv6 is 1280 bytes. If the link layer does not support the MTU requirement, link-layer fragmentation and reassembly must be provided and be transparent to IPv6. A good starting point for understanding MTU and Path MTU Discovery (PMTUD) for IPv6 is with RFC 2460 (http://www.ietf.org/rfc/rfc2460.txt) and RFC 1981 (http://www.ietf.org/rfc/rfc1981.txt).
  • IPsec VPN: When IPsec is used with GRE or manual tunnels, it is important to account for how to adjust the MTU value on the routers to ensure that the router is not forced to perform fragmentation of the IPv4 traffic because of the IPsec header and the additional tunnel overhead. By manually configuring the MTU values prior to IPv6 encapsulation, the MTU requirements can be met for IPv6 without fragmentation concerns. More information on this can be found in any of the IPsec design guides at http://www.cisco.com/en/US/tech/tk583/tk372/tech_design_guides_list.html.
  • IPv6 over wireless LANs (WLAN): IPv6 should operate correctly over WLAN access points in much the same way as IPv6 operates over Layer 2 switches. However, there are considerations to IPv6 with WLAN environments such as managing WLAN devices (APs and controllers) through IPv6 and controlling IPv6 traffic through AP or controller-based QoS, VLANs, and access control lists (ACL). IPv6 must be supported on the AP and controller devices to take advantage of these more intelligent services on the WLAN devices. At the time of writing this chapter, Cisco does not yet have robust IPv6 support on its WLAN product family.
  • IPv6 phone ports: It is important to point out that Cisco supports the use of IPv6-enabled hosts that are directly attached to Cisco IP Phone ports. These IP phone ports are switch ports and operate in much the same way as plugging the host directly into a Catalyst Layer 2 switch.

In addition to the previous considerations, Cisco recommends that a thorough analysis of the existing traffic profiles, memory use, and CPU use on both the hosts and network equipment, and the service level agreement (SLA) language, be completed prior to implementing any of the IPv6 models described in this chapter.


VLAN considerations for IPv6 are mostly the same as for IPv4. When dual-stack configurations are used, both IPv4 and IPv6 traverse the same VLAN. For the current VLAN design recommendations, refer to the Cisco branch–LAN design best practice documents at http://www.cisco.com/en/US/docs/solutions/Enterprise/Branch/Overview.html.

The use of IPv6 on data VLANs that are trunked along with voice VLANs (behind IP phones) is fully supported. Care must be taken to ensure that the correct firmware and proper Cisco Unified Communications Manager configurations are made to ensure that the data and voice VLANs do not allow IPv6 router advertisements (multicast-based) to be bled between VLANs.

For more information on IPv6 and Cisco IP Phones and how to best support VLANs for those endpoints, refer to the section "Unified Communications Endpoints" at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/ipv6/ipv6srnd.html. For information on how to deploy IPv6 on the Cisco Unified Communications Manager, refer to http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/ipv6/ipv6srnd.html.


Choosing an interior gateway protocol (IGP) to run in the branch network is based on a variety of factors: Platform capabilities, IT staff expertise, and the size of network are just a few. In this chapter, the IGP for both IPv4 and IPv6 is Enhanced IGRP (EIGRP). Open Path Shortest First version 2 (OSPFv2) for IPv4 and OSPFv3 for IPv6 can also be used.

As previously mentioned, every effort to implement the current Cisco branch design best practices has been made. Both the IPv4 and IPv6 IGPs have been tuned according to the current best practices for the branch. It should be one of the top priorities of any network design to ensure that the IGPs are tuned to provide a stable, scalable, and fast-converging routing protocol.

EIGRP has been configured to provide authentication for both IPv4 and IPv6 adjacencies and updates.

High Availability

Many aspects of High Availability (HA) are not applicable to or are outside the scope of this chapter. Many of the HA requirements and recommendations are met by leveraging the existing Cisco branch design best practices. The primary HA components described in this chapter are

  • Redundant WAN connections: The deployment of redundant WAN links can vary greatly from customer to customer. Some customers deploy a T1 with a backup connection over a different connection, such as a broadband DSL connection. Redundant Frame Relay connections and/or MPLS connections are also quite common.
  • Redundant routing and forwarding paths: This is accomplished by leveraging EIGRP for IPv4 and IPv6. In some cases, Equal Cost Multi-Path (ECMP) is used, and in other cases (IPsec GRE and manual tunnels), one path is preferred over another, but the secondary path is available for redundancy.
  • High availability of the first-hop gateways: This level of HA applies to any branch and/or WAN head-end connection where there are two or more routers. HSRPv2 for IPv4 and IPv6 can provide first-hop gateway redundancy in this chapter. Cisco also supports gateway load balancing protocol (GLBP) for IPv4 and IPv6.


Cisco recommends that QoS policies be implemented in an application- or service-dependent methodology instead of a protocol- (IPv4 or IPv6) dependent methodology. Basically, if the existing QoS policy has specific classification, policing, and queuing for an application, that policy should treat the IPv4 and IPv6 traffic for that application equally.

The key consideration as far as Modular QoS CLI (MQC) is concerned is the removal of the ip keyword in the QoS match and set statements when IPv6 QoS is required.

Table 8-1 shows the modification in the QoS syntax to support IPv6 and IPv4.

Table 8-1. QoS Syntax Modifications

IPv4-Only QoS Syntax

IPv4/IPv6 QoS Syntax

match ip dscp

match dscp

match ip precedence

match precedence

set ip dscp

set dscp

set ip precedence

set precedence

There are QoS features that work for both IPv6 and IPv4 but require no modification to the command-line interface (CLI), for example, Weighted Random Early Detection (WRED), policing, and Weighted Round Robin (WRR).

Cisco provides an extensive collection of QoS recommendations for the WAN/branch. See the references section at the end of this chapter for a complete list.


Many of the common threats and attacks on existing IPv4 campus networks also apply to IPv6. Unauthorized access, spoofing, routing attacks, viruses, worms, denial of service (DoS), and man-in-the-middle attacks are just a few that plague both IPv4 and IPv6.

There are many new threats with IPv6 that do not exist with IPv4 or they operate differently from IPv4. There are inherent differences in how IPv6 handles neighbor and router advertisement and discovery, headers, and even fragmentation. Based on all of these variables and possibilities, IPv6 security is an involved topic in general, and detailed security recommendations and configurations are outside the scope of this chapter. There are numerous efforts both within Cisco and the industry to identify, understand, and resolve IPv6 security threats. There is an excellent Cisco Press book dedicated to the topic of IPv6 security: IPv6 Security, by Scott Hogg and Eric Vyncke. (See the "Additional References" section at the end of this chapter for more information.)

This chapter points out some possible areas to address within the branch and gives basic examples of how to provide basic protection of IPv6 dual-stack and tunneled traffic.

General security considerations for network device protection that apply to branch profiles are as follows:

  • Controlling management access to the branch routers and switches: All the branch/WAN routers and switches for each profile have configurations in place to provide management access protection to the devices. All routers have loopback interfaces configured for management and routing purposes.

    To more tightly restrict access to a particular switch/router through IPv6, an ACL is used to permit access to the management interface (line vty) by way of the loopback interface. The permitted source network is from the enterprise IPv6 prefix. To make ACL generation more scalable for a wide range of network devices, the ACL definition can permit the entire enterprise prefix as the primary method for controlling management access to the device instead of filtering to a specific interface on the device. The IPv6 prefix used in this enterprise site (for example only) is 2001:db8:cafe::/48. See Example 8-1.

    Example 8-1. Router VTY Configuration

    interface Loopback0
     ipv6 address 2001:DB8:CAFE:1F3::9/128
    ipv6 access-list MGMT-IN
    remark Permit MGMT only to Loopback0
    permit tcp 2001:DB8:CAFE::/48 host 2001:DB8:CAFE:1F3::9
    deny ipv6 any any log-input
    line vty 0 4
    session-timeout 3
    access-class MGMT-IN-v4 in
    password 7 08334D400E1C17
    ipv6 access-class MGMT-IN in     #Apply IPv6 ACL to restrict 
    logging synchronous
    login local
    exec prompt timestamp
    transport input ssh
  • Controlling access through HTTP: At the time of this writing, Cisco IOS does not support the use of IPv6 HTTP ACLs to control access to the device. This is important because switches and routers that currently use ip http access-class ACLs for IPv4 do not have the same level of protection for IPv6. This means that subnets or users who were previously denied access through HTTP/HTTPS for IPv4 now have access to the switch or router through IPv6.
  • Control Plane Policing (CoPP): CoPP protects the router by preventing DoS or unnecessary traffic from negatively impacting CPU resources. Priority is given to important control plane/management traffic. The configuration of CoPP is based on a wide variety of factors, and no single deployment recommendation can be made because the specifics of the policy are determined on a case-by-case basis. You can find more information about CoPP at http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html.
  • Controlling ingress traffic from the branch LAN: Filter which prefixes are allowed to source traffic. This is most commonly done on ingress on the LAN or subinterface on the branch router. Controlling IPv6 traffic based on source prefix can help protect the network against basic spoofing.

    Example 8-2 shows a basic ACL example: applied ingress on a branch router's LAN interface.

    Example 8-2. Basic Branch LAN Ingress ACL

    ipv6 access-list DATA_LAN-v6
    permit icmp 2001:DB8:CAFE:1004::/64 any
    permit ipv6 2001:DB8:CAFE:1004::/64 any
    permit icmp FE80::/10 any
    permit udp any eq 546 any eq 547
    deny ipv6 any any log-input
    interface GigabitEthernet0/0.104
     description VLAN-PC
     ipv6 traffic-filter DATA_LAN-v6 in

    Cisco IOS IPv6 ACLs contain implicit permit entries for IPv6 neighbor discovery. If deny ipv6 any any is configured, the implicit neighbor discovery entries are overridden. It is important that if a manually configured catch-all deny statement is used for logging purposes, the following two permit entries must be added back in: permit icmp any any nd-na and permit icmp any any nd-ns.

  • IPv6 stateful firewall services: Firewalls provide a stateful security inspection for IPv6 traffic entering or leaving a branch network. At the time of this writing, the Cisco ASA 5500 Series, Cisco IOS Firewall, and Cisco IOS Zone-based Firewall support IPv6 inspection at various levels. It is critical that you consult with Cisco documentation, a Cisco account team, and/or a Cisco partner to understand which Cisco Firewall solution is appropriate for the customer environment.
  • Disabling unused services: Many services, such as HTTP server, are supported for IPv4 and IPv6. Enabling or disabling these services generally applies to both protocols. It is a long-standing recommendation to disable any services that are not in use.


IPv6 multicast is an important service for any enterprise network design. One of the most important factors to IPv6 multicast deployment is to ensure that host/group control is handled properly in the branch LAN. Multicast Listener Discovery (MLD) in IPv6 is the equivalent to Internet Group Management Protocol (IGMP) in IPv4. Both are used for host multicast group membership control. MLD snooping is the ability to control the distribution of multicast traffic only to the ports that have listeners. Without it, multicast traffic meant for only a single receiver (or group of receivers) would be flooded to all ports on the branch LAN switch belonging to the same VLAN. In the branch LAN, it is important that the switches support MLD snooping for MLD version 1 and/or version 2.

Today, Cisco IOS supports the following Protocol Independent Multicast (PIM) implementations: PIM-SM, PIM-BSR, PIM-SSM, Bidirectional PIM, Embedded-RP, and Multiprotocol BGP for the IPv6 Multicast Address Family.

There are several documents on Cisco.com and within the industry that describe IPv6 multicast in detail. Other than generic references to the commands that are used to enable IPv6 multicast and requirements for Embedded-RP definition, no other configuration notes are made in this chapter. For more information, refer to the following URLs:


Management for IPv6 is under development and has a long way to go. Many of the traditional management tools used in IPv4 also support IPv6. In this chapter, the only considerations for management of the branch network are related to basic control of management services (Telnet, SSH, and SNMP). All the IPv6-enabled devices in the two branch profiles described are manageable over IPv6 through the previously mentioned services except SNMP.

The deployment of Simple Network Management Protocol (SNMP) for IPv6 is the same as with IPv4. In the branch profiles described in this chapter, SNMPv3 (AuthNoPriv) can provide polling capabilities for the Cisco Network Management Systems (NMS) servers located in the HQ data center. Here is an example of the SNMPv3 configuration used in the branch routers in this chapter:

snmp-server contact John Doe - ipv6rocks@example.com
snmp-server group IPv6-ADMIN v3 auth write v1default
snmp-server user jdoe IPv6-ADMIN v3 auth md5 cisco1234

If information needs to be sent to a Cisco NMS server, an SNMP host can be defined. The host can be defined to send SNMP information over IPv4 and/or IPv6:

snmp-server host 2001:DB8:CAFE:100::60 version 3 auth jdoe

Another area of management that must be thoroughly researched is that of address management. The process of assigning large hexadecimal addresses to many network devices should, at some point, be automated or at least made more user-friendly than it is today.

Today, one way to help with the deployment of address prefixes on a Cisco router is through the use of the general prefix feature. This feature enables the customer to define a prefix or prefixes in the global configuration of the router with a user-friendly name. That user-friendly name can be used on a per-interface basis to replace the usual IPv6 prefix definition on the interface. The general prefix feature is most applicable in deployments where there is or can be frequent changes in the address prefix, such as during a pilot or in early production when the final IPv6 address policy is not fully nailed down. The following is an example of how to use the general prefix feature:

  • Step 1. Define the general prefix:

    br1-1(config)# ipv6 general-prefix BRANCH-1 2001:DB8:CAFE::/48
  • Step 2. Configure the general prefix named BRANCH-1 on a per-interface basis:

    br1-1(config-if)# ipv6 address BRANCH-1 ::1005:0:0:0:1/64
  • Step 3. Verify that the general prefix was correctly assigned to the interface:

    br1-1# show ipv6 interface g1/0.100
              GigabitEthernet1/0.100 is up, line protocol is up
                 IPv6 is enabled, link-local address is FE80::217:94FF:FE90:2829
                 No Virtual link-local address(es):
                 Description: DATA VLAN for Computers
                 Global unicast address(es):
                 2001:DB8:CAFE:1005::1, subnet is 2001:DB8:CAFE:1005::/64

You can find more information on the general prefix feature at the Cisco IOS IPv6 documentation page at http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con_ps10591_TSD_Products_Configuration_Guide_Chapter.html#wp1132473.

Cisco supports the management of IPv6-enabled network devices through a variety of network management products to include DNS, DHCPv6, device management and monitoring, and network management, troubleshooting, and reporting. You can find more information on the various Cisco Network Management solutions at http://www.cisco.com/en/US/products/sw/netmgtsw/index.html.

Chapter 11, "Managing IPv6 Networks," goes into greater detail on IPv6 management.

Scalability and Performance

This chapter is not meant to analyze scalability and performance information for the various platforms tested. The coverage of scale and performance is more focused on general considerations when planning and deploying IPv6 in the branch versus a platform-specific view.

Scalability and performance considerations for the branch network devices are as follows:

  • Traffic utilization: In IPv6 implementations, it is common to see a change in traffic utilization ratios on the branch network links. As IPv6 is deployed, IPv4 traffic utilization is often reduced as users leverage IPv6 as the transport for applications that were historically IPv4-only. There is often a slight increase in overall network utilization, which usually derives from control traffic for routing and, if deployed, tunnel overhead.
  • Routing/forwarding: It is important to understand the routing and forwarding capabilities of the branch routers. If the existing branch router is already running at high CPU and memory utilization rates for the handling of IPv4 routing tables and updates, it is a bad idea to add IPv6 to the existing router. If the routing platform is hardware based, the impact is less of a concern.
  • ACL processing: It is imperative that the deployment of ACLs be carefully planned. IPv6 ACLs in the branch routers are used for QoS (classification and marking of ingress packets from the access layer), for security (controlling DoS, snooping, and unauthorized access for ingress traffic in the access layer), and for a combination of QoS + security to protect the control plane of the router from attack. The router can also provide Cisco IOS stateful firewalling services, intrusion detection systems/intrusion prevention systems (IDS/IPS), and voice services for IPv4 and new services for IPv6. Advanced services that are added to the branch router should support both IPv4 and IPv6. Performance will be impacted with all these added services plus the newly enabled IPv6 configuration.

Cisco has an IPv4/IPv6 performance comparison document that goes into some detail on these topics at http://www.cisco.com/web/strategy/docs/gov/IPv6perf_wp1f.pdf.

3. WAN/Branch Implementation Example | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020