Home > Articles > Software Development & Management

Network Layer/Internet Protocols

IP is the workhorse of the Network layer within the TCP/IP suite. This excerpt covers IP operation, fields, and functions. End hosts and routers use ICMP (Internet Control Message Protocol) as a control, messaging, and diagnostic tool. ICMP utilizes IP to deliver its messages and is considered an integral part of IP.
This chapter is from the book

This chapter is from the book

You will learn about the following in this chapter:

  • IP operation, fields and functions
  • Fragmentation and reassembly of datagrams
  • ICMP messages and meanings


IP (Internet Protocol) does most of the work in the TCP/IP protocol suite. All protocols and applications within the TCP/IP suite run on top of IP and utilize it for logical Network layer addressing and transmission of datagrams between internet hosts. IP maps to the Internet layer of the DoD and to the Network layer of the OSI models. ICMP (Internet Control Message Protocol) is considered an integral part of IP and uses IP for its datagram delivery; we will discuss ICMP later in this chapter. Figure 3.1 shows how IP maps to the DoD and OSI models.

How Do I Buy a Ticket on the IP Train?

The phrase "runs on top of" might sound as if an application or protocol is buying a ticket to ride on an IP train. This term is not restricted to IP. In reality, it is industry jargon used to describe any upper-layer protocol or application coming down the OSI model and utilizes another lower-layer protocol's features (in this case IP at the Network layer).

IP provides an unreliable, connectionless datagram delivery service, which means that IP does not guarantee that an IP datagram successfully reaches its destination; rather it provides best effort of delivery, which means it sends it out and hopes it gets there. IP simply adds logical source and destination network layer addresses and delivers the datagram relying on other layers to guarantee it gets to its destination. If there is a problem with delivery, IP relies on ICMP to send messages when it encounters an error. When IP encounters an error in delivery, it simply trashes the datagram, causing an ICMP message to be sent to the source host detailing what kind of delivery problem occurred. IP relies on upper layers to provide reliability; for example, TCP (which will be discussed in more detail in Chapter 8, "Transmission Control Protocol (TCP)").

Figure 3.1 IP provides logical addressing and connectionless delivery of datagrams for all protocols within the TCP/IP suite.

The Internet Protocol's primary function is logical network layer addressing of hosts and delivery of information in the form of datagrams between hosts. IP addressing is discussed in detail in Chapter 2, "IP Addressing." IP also performs other important functions such as fragmentation and reassembly, which are necessary when datagrams are too large to be sent by a source host and must be broken up into smaller datagrams. Because IP is connectionless it does not require a connection between hosts. It does not sequence, acknowledge, or control the flow of data between hosts. IP treats each datagram as a separate entity; it merely addresses the datagram and sends it out, hoping it reaches the destination.

IP receives a stream of data from UDP or TCP, breaks up this information into chunks, and addresses and packages each piece as a datagram, which then can be sent to a destination host across the network. Routers and routing protocols determine the path selection between a source and destination, which we discuss in more detail in Chapters 5, "IP Routing" and 6, "Routing Protocols."

RFC 791

RFC 791 defines IP, and its fields and functionality. In this chapter we will look at an IP header and its fields and examine the other protocols that reside on the Internet layer. We will discuss IP routing in Chapters 5 and 6.

IP Header

Figure 3.2 shows the format of an IP datagram as defined by RFC 791. An IP header contains a minimum of 20 bytes, unless options are present. Figure 3.3 shows an IP header as seen through a Sniffer protocol analyzer. We will describe each field after the figures.

Figure 3.2 The Internet Protocol header provides for identification of logical source and destination network addresses.

Figure 3.3 Note the Ethertype value contained within the DLC (Data Link Control) header states that protocol type 0x0800 or IP is the protocol being carried within this frame.

Take a look at the IP header in Figure 3.3. The first field is the version type, which should always be version 4, the official standard. This is followed by the header length, indicating the size of the IP header as 20 bytes. Type of service (ToS) values follow. Most often the ToS value, as in this case, will have a value of zero because ToS is seldom used. However, this trend is changing as ToS becomes more understood and more vendors implement it successfully in their products. New applications capable of setting these bits to influence a router's routing of datagrams are emerging. This allows them to request from routers a certain level of ToS service for transmitted data.

The total length of the datagram is 40 bytes, which includes the IP header and data being carried within the frame. The IP ID value given to this datagram is 25276. Note that in the Flags field the datagram can be fragmented if necessary, and that this is the last fragment. Because the fragment offset has a value of zero, we can deduce that this is the first, last, and only fragment within the stream.

The TTL value currently is set to 59 seconds, which is the amount of time left for this datagram to live on the internetwork. The next protocol being carried within the frame is TCP. IP uses the checksum value to identify frame damage. The sending host's logical IP address is and the destination host's address is


The value within the 4-bit version field identifies the version of IP being implemented. This value will always be version 4. It is the most current and popular version of IP.

Internet Header Length

The 4-bit header length field identifies the size of the IP header in 32-bit words. All IP headers must have a minimum of 20 bytes in size unless additional options are implemented and specified within the option field, which we will discuss later in the "Type of Service" section of this chapter.

Type of Service

The ToS bits (8 total bits) within the IP header can influence the path datagrams take when being forwarded by routers from source to destination. ToS bits allow upper applications and processes to indicate the type of quality or service they require from a router. Until recently, the use of the ToS bits has been nonexistent. However, many companies now implement them to facilitate more intelligent path selection. If ToS has not been implemented, this field will have a value of zero. Because the use of ToS is uncommon, zero is an expected value. RFC's 1340 and 1349 describe the specific use and functions of these bits. The following explains the various ToS bits.

Bits 0–2: Precedence Bits

Bits 0–2, known as precedence bits, when used in the following combinations mean different things, and typically only the government uses these implementations to define the importance of a datagram. This value uses the options field within the IP header, discussed later in this chapter, to further describe the type of precedence requested. The precedence value typically describes the type of security levels requested defined by the Defense Intelligence Agency. Table 3.1 describes the various precedence bits set.

Table 3.1 Bits 0–2 = Precedence

Bit Position



Routine information


Priority information


Immediate delivery




Flash override


Critical information


Internetwork control


Network control

Until recently most applications did not support or use precedence bits. However, they comply with governmental network implementations, which require multilevel security functions. No further discussion of these bits will follow. Precedence is described in further detail in Chapter 8. The organization that chooses to implement these bit must specifically define the precedence bits, and their use and meanings.

The next three ToS bits are the most commonly used for influencing traffic patterns.

Bit 3

Bit 3 can have one of two values:

  • 0 = Normal delay

  • 1 = Low delay

Delay is based on the end-to-end propagation delay of data transmitted over a link. When multiple paths exist to a destination, an application can direct routers en route to select the path with the least delay—a faster path.

Bit 4

Bit 4 can have one of two values:

  • 0 = Normal throughput

  • 1 = High throughput

When an application requires a path to a destination that offers high throughput rates, it sets the throughput bit to 1. Routers forward traffic along paths that support the highest possible data rate, measured as the bandwidth capacity of a link between source and destination.

Bit 5

Bit 5 can have one of two values:

  • 0 = Normal reliability

  • 1 = High reliability

Routers measure a link's reliability by the number of errors encountered and lost datagrams it experiences when forwarding or receiving across an interface. If multiple paths exist and one appears to be more reliable than the other, a router forwards traffic for applications, setting the reliability bit to 1 across this interface. Critical applications that cannot tolerate data loss may request this type of service.

Bits 6 and 7 (Reserved)

Bits 6 and 7 are reserved and not currently used.

Upper-layer applications or processes can request for routers to deliver their data along paths that meet their service requirements. For ToS delivery to work all routers and routing protocols within the path from source to destination must understand, and be configured to forward datagrams based on the ToS designation. Not all routing protocols understand these bits. The following routing protocols understand ToS:

  • OSPF


  • IGRP

  • BGP

The following protocols do not understand ToS:

  • RIP v1

  • RIP v2

Although a routing protocol might have the capability to understand and act upon these bits, it still requires configuration. If someone has not configured the router to support ToS, it simply ignores this information and forwards the datagram the best it can. Let's look at an example of how ToS works. When an application requests datagrams to be sent through a low delay path, it sets bit 3 to a value of 1. Routers along the path attempt to send datagrams across links offering faster transmissions, such as 100Mb Ethernet versus slower WAN links. Keep in mind that delay is measured by the round-trip propagation delay across the link. Therefore, a link with a lower delay would be the preferred path.

High throughput translates to high-capacity links, which have the capability to carry larger amounts of data in a shorter time frame. This is useful for large file transfers. Routers measure the capacity of a link in terms of bandwidth, which is the transfer rate in bits across the interface. For example, an Ethernet 100Mbps link carries 100 million bits per second, which is faster than a 10Mbps (10 million bit per second) interface. If reliability is the objective, such as the case in an application performing critical processes or requiring security, an application _can request a more reliable transmission path by setting bit 5 to a value of 1. This might be a transaction-based processing application, which requires access to a company's fault-tolerant backbone.

It is very important to understand that by setting these bits, you change the way routers route traffic. Without a thorough understanding of the types of protocols, applications, traffic flows and protocol timers within your network, this manipulation could have catastrophic results. It is imperative that you baseline your network thoroughly before attempting to implement them. When properly used, they can dramatically increase the performance of your network and network applications.

Total Length

The 2-byte total length field within the IP header defines the length in bytes of the entire IP datagram. This value includes the IP header and data being carried within the datagram.


The sender gives each IP datagram an ID value prior to transmission, which is found in the 2-byte identification field. This ID uniquely identifies a datagram or stream of datagrams. The destination host uses this ID to reassemble the datagrams received. When a source host's IP process receives a large stream of contiguous data from UDP or TCP for datagram packaging, it breaks up this stream (fragmentation) when it receives a packet that is too large for the transmission medium. IP then assigns all datagrams belonging to the stream the same ID.

When transmitted from source to destination, datagrams can take different paths with widely varying characteristics, causing them to arrive out of order. The destination host uses this ID to recognize that all the datagrams belong to a stream. It then reassembles them in the correct order based on the fragment offset value, which we will explain later in this section.


Bit 0 = Reserved. Must be a value of zero.

Bit 1 = Can have one of two values:

  • 0 = May Fragment

  • 1 = Don't Fragment

The 3-bit flags field is used on hosts and gateways for fragmentation purposes. If a host or a gateway supports fragmentation, it can break a stream of data into smaller pieces before transmission. If it does not support fragmentation (the don't-fragment bit is set), the host or gateway cannot fragment the stream. Typically, the sending host has the responsibility of performing fragmentation. The destination host reassembles the datagrams into the original stream before passing it up to the upper layer (TCP or UDP) for processing. However, this is not always the case.

When a source host sends a datagram that reaches a segment and is too large to be forwarded, the gateway performs the fragmentation, breaking the datagram into smaller units acceptable for the media. Having intervening gateways perform fragmentation of datagrams in transit is not a good idea. Routers forced to perform this function require additional resources and add unnecessary overhead and latency to the delivery of the datagram. Because different underlying network architectures support varying frame sizes, find out what the lowest value MTU (Maximum Transmission Unit) size is for your network and configure your hosts and gateways to support it. For example, Ethernet has a maximum frame size of 1518 bytes, whereas Token-Ring frames might range from 4,500 bytes to 17,800 bytes.

The DF bit has another use. Some implementations use the DF bit to dynamically discover the MTU size of the network end to end. If intervening routers have this bit enabled, when an end host attempts to send a datagram that is larger than the next segment along the transmission path, the router will not forward the frame. Instead, the router drops the datagram and kicks back to the source host an ICMP message indicating the datagram is too large and has exceeded the maximum segment size. The host then can use this information to resize its next datagram. This process will continue until the sending host has discovered the proper size to send, allowing intervening routers to simply forward datagrams without performing fragmentation en route to its destination.

Bit 3 = Can have one of two values:

  • 0 = Last Fragment

  • 1 = More Fragments

The Last or More Fragments bit indicates whether this is the last datagram within a stream or more datagrams are to follow. If there is only one datagram this bit will be zero, indicating that this is the first and the last, meaning it is the only one. When a destination host receives a datagram, it notes the ID value and checks whether this bit is a one or zero, indicating that this is the last datagram or more are expected. If it expects more, this host holds the datagrams in memory until all others with the same ID arrive and the stream is reassembled and passed up to the appropriate upper-layer protocol for processing. By matching the IDs and referencing the last or more bit, the host knows when to stop expecting future datagrams within this stream and when to start reassembling them.

Fragment Offset

The sending host uses the 13-bit fragment offset value to identify the position of the datagram with the stream being sent—the order in which this datagram belongs when more than one is sent with the same IP identification. The sending host always assigns the first datagram with an offset value of zero. It assigns the second, third, or more datagrams with a number based on the MTU size. The receiver uses the fragment offset value to put the datagrams within the same stream back together upon reception or detect that one is missing within the stream.

For example, if a sending host has three datagrams to send that belong to a stream, it goes through this process:

  1. Assigns each of these datagrams the same ID.

  2. Sets the More Fragments bit to a one on the first two datagrams to indicate that these are not the only datagrams in this stream and that more are to follow.

  3. Sets the Last Fragment bit on the final datagram in the stream.

  4. Each datagrams offset bears an offset value identifying where this datagram belongs in the stream.

Figure 3.4 shows an example of a sending host and a receiving host using the fragment offset value to determine in what order datagrams belong. In Figure 3.4 Station A wants to communicate with Station B and sends a single datagram containing 1500 bytes of information on the wire. Note that the local segment attached to segment A can accept a maximum transmission unit (MTU) size of 1,518 bytes, which is sufficient to support this frame size. The datagram makes it through Router 1, which forwards it on to Router 2 as is. Note that the segment between Router 1 and 2 also accepts an MTU of 1,518.

In Figure 3.4 the WAN segment between Routers 2 and 3 will not accept a segment larger than 512 bytes, so Router 2 must break up the original datagram sent by Host A to fit this datagram on the wire; this is called fragmentation. There now are three datagrams forwarded across this link to Router 3 and ultimately to their final destination, Host B. Once these datagrams reach Host B, this host performs the reassembly prior to sending them up to the upper-layer process. Host B (the receiving host) uses the IP identification field, Last and More Fragments bit, and the fragment offset to piece the datagram back together.

Figure 3.4 In this figure, Host A sends a 512-byte datagram, which is too large for the WAN. Router 2 breaks up the datagram (fragments) into smaller chunks, forwarding them. The destination host is responsible for _reassembly.

Using Figure 3.4 as an example, the receiving host expects to find and reassemble the datagrams in the following order:

  1. The first datagram in a stream always has an offset value of zero, indicating the first one in the stream.

  2. The second datagram has an offset value of 512.

  3. The third datagram has an offset value of 1024.

The receiver stores datagrams in its memory buffer waiting for messages within the stream to arrive. However, it does not always receive the datagrams in order. For example, if the second datagram arrives first with offset 512, the receiver knows to expect several others because

  • The sending host has set More Fragments bit in the second datagram.

  • This is not the Last Fragment.

  • The receiver has not received a datagram with the same ID containing fragment offset zero, which indicates the beginning.

Because it has received a datagram with the More Fragments bit set and has not received a datagram with a Last Fragment bit set, it knows to expect more datagrams. Once the receiver gets all the fragments within the stream, it can put them in the correct order and pass them up to the upper-layer application for processing.

Figures 3.5, 3.6, and 3.7 depict another example of fragmentation and reassembly as seen through a Sniffer. Figure 3.5 details the first datagram within the stream; Figure 3.6 details the second datagram within the stream and Figure 3.7 details the last datagram within the stream. In Figure 3.5 notice that in frame 1 (highlighted in the detail pane), the IP ID value of this frame (frame 1) and all other frames (frames 2–5) shown in the summary pane bear the same value of 2052, shown as "continuation of indent=2052." This means that frames 1–5 all belong to stream 2052.

Note that the sending host has set the More Fragments bit within the first frame, indicating the this datagram has more fragments or datagrams within this stream. In other words, this is not the last datagram. Also note that the sending host set the fragment offset to zero, indicating the first fragment in series 2502.

Figure 3.5 The More fragments bit is set indicating more datagrams will follow. The fragment offset set to zero indicates this is the first datagram within the stream.

Figure 3.6 shows the second fragment in stream 2502. Note that the More Fragments bit is set, indicating that more datagrams follow this one. Note that the fragment offset is 1480, which indicates this is not the first datagram (because it is not zero). Because the last fragment bit is not set, we know it is not the last but somewhere in the middle (in this case second). The destination host uses this information to put the fragments in the stream in the right order when it receives all the fragments within the stream.

Figure 3.6 The fragment offset is used by the receiving host to reassemble datagrams.

Figure 3.7 skips fragment 3 and shows the final fragment in the stream. Note that this fragment belongs to the stream because it has the identification value of 2502 like all the other fragments. We know this is the last fragment because Last Fragment is set. The fragment offset of 7400 is higher than the previous fragments so the destination host knows this is the last fragment and starts at the offset.

Time To Live

All devices processing a datagram decrement the 1-byte TTL value, which is measured in seconds. This value has two main purposes:

  • To define the maximum time a datagram may live on the Internet prior to being discarded.

  • To ensure that undeliverable datagrams also are discarded.

Before routers existed on the Internet, to ultimately remove a lost datagram from the network it was necessary to recognize and limit the time it traversed the network. The TTL timer was used for this purpose. It remains today and is used for various purposes, such as tracing a route to a destination host or network, which we will discuss later in this chapter. Basically, whenever a device such as a gateway processes a datagram, it must decrement this value by at least one before forwarding it. Each TTL value indicates a value of one second, which is more time than it should take for a router to process a datagram. This value can typically be equated to a hop count indicating the datagram has passed through x number of routers by determining how many TTL units this value has been decremented.

Figure 3.7 Note the Last fragment bit is set indicating to the receiver that this is the last datagram within the stream.

A network administrator can configure the starting TTL value but this value cannot exceed 255 (seconds). The general rule is that a device may not forward a datagram with a TTL value of 1 or less. If a datagram has lived on the wire for 255 seconds and has not reached its ultimate destination, it has lived too long on the network and should be removed. When this occurs, the device that the TTL expired on sends an ICMP message back to the source indicating that the datagram TTL time has exceeded. We will discuss ICMP messages later in this chapter.


The 1-byte protocol field contains a value that specifies the next protocol expected within the datagram. This value will contain one of two values:

  • 06 (TCP)

  • 17 (UDP)

IP uses these values to identify to which upper-layer protocol to hand the information when it receives it.

Header Checksum

Because IP is a connectionless protocol, it does not implement any type of error correction mechanism, such as sequencing and acknowledgments. IP simply sends datagrams out, addresses them, and hopes they reach their destination. Therefore, IP uses a simple checksum, contained in this 2-byte field, to verify the integrity of the IP header and the data being carried to ensure that nothing has happened to the bits while in transit between source and destination hosts. Intervening devices must recalculate and verify this checksum value along the way because some of the fields within the IP header change while in transit (for example, time to live). If at any point in time a device deems this value invalid due to damage, it trashes the datagram without sending a message to the source. IP relies on upper-layer protocols to detect the loss of a datagram and recover from it (retransmit).

Source Address

The sending host places its logical Network layer (IP address) address within this 4-byte field for identification purposes.

Destination Address

This 4-bit field identifies the recipient's logical network layer address. This logical 32-bit IP address identifies the destination network and host.


Hosts or gateways can implement optional parameters; when used, this variable-length field defines them here. However, options do not have to exist within a datagram; if implemented, all hosts and gateways must recognize and support their implementation. This could include the use of a security option as specified within by the precedence value used in the ToS field.


IP uses this variable-length field only when an IP header does not end on a 32-bit boundary. Because the IP header is expressed in 32-bit words, padding is used to ensure that this happens.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT 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 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@informit.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 InformIT. 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.informit.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