Chapter 1: Network Overview

Knowledge of the structure of Internet Protocol (IP) packets is a fundamental part of understanding the Internet and how information moves from one point to another. The benefits of such knowledge extend to virtually all networking disciplines, not the least of which is intrusion detection. Rules-based intrusion-detection mechanisms, for example, can flag packets as suspicious if their structure mimics that of a known malicious string. While this is happening, another rule might cause an action in response to a packet that has no conceivable reason to exist, as when both the SYN and RST flags are set. There are many ways to probe and attack from within a packet, and the problem only gets worse as a network gets larger. The shotgun approach of enabling all possible Intrusion Detection Systems (IDS) rules is sure to fail in most environments, particularly when busy, high-speed circuits threaten to overtax IDS deployments that must decode every packet on the wire. In IP networks, bit-level expertise cannot be overvalued when you are designing solutions or choosing the most appropriate defense technologies.

The topic of this chapter—the structure and functions of TCP/IP—is uniquely appropriate in any discussion of intrusion-detection techniques. This chapter begins with a clarification of key terms and concepts, and then it discusses the genesis of current reference models that were introduced in the early 1980s. Following that is a detailed examination of TCP/IP, and the final section describes modern networking.

Key Terms and Concepts

It is important to clarify certain key terms that this chapter uses. Readers who know the standards that are under review by more than one name will see them here as TCP/IP and the OSI Model, which represent Transmission Control Protocol over Internet Protocol and Open Systems Interconnection, respectively. Because all the popular terms are essentially correct, it is best to declare this common ground before the details are discussed.

When reading technical information or preparing for a network-analysis effort, it helps to have certain issues and concepts in mind. These items serve that purpose regarding TCP/IP and the OSI Model:

• All implementations are not created equal. Conforming to standards made by developers and manufacturers is practically voluntary.

• In nearly all real-world cases, the OSI Model nomenclature is used in documents and discussions, regardless of the technology.

• Although it can be made to work, communication between TCP/IP and the OSI Model systems can have undesirable effects, at least in the form of more difficult implementation.

Brief History of the Internet

The goal that was realized by the creation of this protocol mix, which is often called a “protocol stack,” is a means for open communication between disparate computers. The driving forces behind the Internet was the United States Department of Defense (DoD), specifically the Defense Advanced Research Projects Agency (DARPA), and two international organizations: the International Organization for Standardization (ISO) and the International Telecommunications Union (ITU).

DARPA began work on its network, ARPANET, in 1968, which went into full production in 1970. At the time, the protocol in use was the ARPANET Network Control Program (NCP) host-to-host protocol, and the first five nodes added belonged to Bolt, Beranek, and Newman (BBN); Stanford University; UCLA; UC Santa Barbara; and the University of Utah.

The number of nodes on ARPANET grew considerably over the next few years, which lead to various problems that were largely viewed as symptoms of technical limitations. In July 1980, the Office of the Secretary of Defense directed that a set of DoD standard protocols be used on all defense networks. The protocols have the following official designations:

• RFC 791, Internet Protocol

• RFC 793, Transmission Control Protocol

These are the most current RFC numbers and descriptions; the authoritative organization of the day was the Internet Configuration Control Board (ICCB), who designated the original releases as RFC 760, DoD Standard Internet Protocol and RFC 761, DoD Standard Transmission Control Protocol.

In the mid to late 1970s, the ITU and ISO were working independently to develop an open set of standards for network architectures. This presented significant challenges that DARPA did not encounter, which, by comparison, operated in a controlled environment. The ISO and ITU architects faced the daunting task of convincing equipment manufacturers to agree with each and every standard.

ISO and ITU established a positive vendor relationship with Honeywell Information Systems, which worked with the international teams. In 1984, the ITU and ISO teams merged their respective standards work into a single document, and much of the final product came from Honeywell engineers. The standards document was released under the umbrella name Open Systems Interconnection, which is now referred to as the OSI Reference Model (or simply the OSI Model). The cooperating international organizations designate the specification as follows:

• ITU-T, X-Series Recommendation X.200

• ISO 7498, Open Systems Interconnection, Basic Reference Model

The ARPANET transition to TCP/IP happened between October 1981 and October 1983. During this time, the protocols were intensely researched and scrutinized by their developers. The official release came on January 1, 1983, and the Internet was born. The headstart that was gained by the development period and 1983 release date is said to be the reason that TCP/IP is now the global standard for Internet communications. Now that you have an abridged knowledge of the history of the Internet it’s time to explore the OSI Model and TCP/IP.

Layered Protocols

Internet hosts communicate by using a special software mechanism called layers (or layered protocols). The OSI Model has seven layers, and TCP/IP has four.

---

Note – The depiction of layers might depend on which reference document is chosen as the authoritative model. Although most Internet Engineering Task Force (IETF) documents reference TCP/IP as having the four layers shown in Figure 1-1, RFC 1983, “Internet User’s Glossary,” lists the number of layers at five. Commercial documents also reflect this difference, but Cisco Systems, the current and long-standing leader in network technologies, teaches in CCENT/CCNA ICND1 Official Exam Certification Guide (Odom 2007) that TCP/IP has four layers.

---

Figure 1-1 makes it easy to understand why the world is comfortable with TCP/IP as the Internet standard protocol suite, but it still uses the OSI Model terms in documents and discussions. The end result is the same with both versions, but TCP/IP has an edge over the OSI Model in terms of simplicity. The Internet Society can divide TCP/IP into two areas of responsibility in support of developers and users: The lower three layers (link, Internet, and transport) are the communication layers, which focus on networking requirements, and the application layer covers host software. On the other hand, the OSI Model gives the technical community a clear set of terms for communication between humans. A minor point is the fact that many readers interpret Figure 1-1 to be based on “incorrect” names. For example, the link layer is also known as the access layer and media access layer.

Figure 1-1

TCP/IP and OSI Model comparison

As previously mentioned, OSI Model nomenclature is used in nearly all discussions and documents, even though TCP/IP is the Internet standard. Figure 1-1 shows that TCP/IP is at Layer 2 if the counting starts at the bottom and moves up; however, because it is functionally the same as the OSI Model network layer, referring to it as a Layer 3 protocol causes no problems.

Industry technical parlance involves specific names for data units in the context of the TCP/IP and OSI Model layers. For the data link layer, the term is frames, the network layer term is packets, and the transport layer term is segments. In the broader context of the Internet, a unit of data is called a datagram (or an IP datagram). This is a case of TCP/IP terminology being applied to the OSI Model layers, but it is technically accurate. Architects of the OSI Model devised a more elegant way to describe data chunks. OSI Model documents use the term Protocol Data Unit (PDU) for all units of data and, as a differentiator between layers, it simply uses the layer number as a prefix to PDU. As such, a TCP/IP Ethernet frame is an OSI Model Layer 2 PDU. Note that the word datagram is sometimes used interchangeably with PDU or packet in RFCs and commercial documents. Table 1-1 lists the TCP/IP and OSI Model layers and functions.

Table 1-1 OSI Model Layers

Consider an analogy of what is required for a personal computer in Redmond, Washington, to converse with a mainframe computer in Armonk, New York:

1. The first, and most obvious, requirement is that both computers must be physically connected to a network that, in turn, has physical connectivity between the locations.

2. The computers need to be told that they can talk and decipher the communication that comes their way as being real or garbage (errors).

3. At least one of the computers in the conversation must know the address of the other computer and the wherewithal to initiate the data communication.

4. The data traffic might be heavy, so both computers need to know how to go with the flow and have their data arrive in one piece at the other end.

5. The participants must have the sense not to talk at the same time. They must know when to shut up!

6. Knowing that they are foreign to each other, an interpreter must be available.

7. The personal computer and mainframe can exchange information.

Disregarding that this analogy is fiction, the conversation became easier because traffic cops along the route did not spend time meeting all the same requirements. All they needed was physical connectivity, a common language for communication, and a list of recipient addresses that they could share.

The casual analogy of two computers that need to talk as people do describes a seven-layer communication model. Reality departs from such an analogy, mostly because of these details:

• Same-layer interaction. The layered networking model has a peer-to-peer interaction between equal layers on different computers.

• Adjacent-layer interaction. Layered networking involves an interaction between adjacent layers on the same computer.

The same-layer interaction is how each layer communicates its intended action to its peer on the receiving end of a connection. Adjacent-layer interaction involves attaching a PDU to a protocol header as it moves through the layers, which is a process called encapsulation. As its name implies, a header is at the front of the transmitted data and is the first thing that the receiving host interprets. It contains source and destination addresses, and it can include error checking or other fields. Figure 1-2 and Figure 1-3 show same-layer and adjacent-layer communications.

Figure 1-2

OSI Model same-layer and adjacent-layer interactions

Figure 1-3

TCP/IP same-layer and adjacent-layer interactions

An example using TCP/IP hosts shows how layered protocols enable communication. Assume that a host application program needs to send data to another host that is several hops away. Figure 1-4 illustrates the following steps:

1. The application program at the originating host passes its data, the destination address, and other parameters required to the transport layer as arguments in a system call.

2. Figure 1-4

   Data transmission

3. The transport layer encapsulates the data by attaching it to a header that it has created and then passes it to the Internet layer.

4. The Internet layer encapsulates the data inside an IP header and passes it to the link layer.

5. The link layer (in this example, Ethernet) encapsulates the data as a frame inside an Ethernet header and trailer for transmission by the physical media.

6. Data is encoded as bits on the physical medium. This is called electrical encoding.

7. The Ethernet frame arrives at the interface of a router that is on the same segment. The router also has a connection to the wide area network (WAN). This router functions as a gateway.1

8. The IP packet is extracted and routed to the next hop in the path. At this point, the entire operation is internal to the router, which effectively switches the packet from its Ethernet interface to a WAN interface; in this example, it is a serial interface. This is path switching, not switched Ethernet.

9. The serial interface is configured to use high-level data link control (HDLC) as the WAN protocol, so the packet is encapsulated inside an HDLC frame, and then forwarded over the WAN to the next hop in the path. HDLC is a Layer 2 protocol in OSI terminology.

10. At each hop, the IP packet is extracted, switched to an outbound interface, and encapsulated as required for transmission to the next hop.

11. Routing along the way to the final destination is facilitated by routing protocol operations in each hop. Path selection is based on IP address tables (routing tables) and routing algorithms, such as Open Shortest Path First (OSPF) and Interior Gateway Routing Protocol (IGRP). Large networks that are logically divided into “domains” also use special routing protocols for interdomain path selection, such as Border Gateway Protocol (BGP).

12. At the destination router, the IP packet is extracted and switched to an outbound Ethernet interface; the destination host is on this segment.

13. The packet is encapsulated inside an Ethernet header and trailer.

14. The Ethernet frame is encoded in electrical bits, transmitted over the physical medium, and delivered to the interface of the destination host.

15. The Internet layer extracts the IP packet from the Ethernet frame and passes it to the transport layer.

16. The transport layer ensures that all segments are in order and delivers the data to the host application program.

TCP/IP Protocol Suite

Specifications in RFC 1122, “Requirements for Internet Hosts—Communication Layers,” state that Internet hosts must implement at least one protocol from each layer of the TCP/IP protocol suite. In light of the fact that the link, Internet, and transport layer protocols must be operational for an implementation to work, it might appear as though the IETF is “requiring the obvious.” Additional details clarify the requirement by distinguishing two categories of application layer protocols: user protocols that provide services to users, and support protocols that enable common system functions. RFC authors explain that the most common examples of each are as follows:

• Application layer user protocols. Telnet, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP).

• Application layer support protocols. Simple Network Management Protocol (SNMP), BOOTP, Reverse Address Resolution Protocol (RARP), and Domain Name System (DNS).

Tables 1-2 through 1-5 offer brief definitions of these protocols and others that are widely used today. To be consistent with typical industry language, OSI Model terms describe the layers at which each protocol operates.

Table 1-2 Application Layer Protocols

Table 1-3 Session Layer Protocols

Table 1-4 Transport Layer Protocols

Table 1-5 Internet Layer Protocols

Although developers have latitude for implementing the TCP/IP protocol suite, there are some stringent requirements to consider. A good example is the robustness principle, which stresses that software is written in such a way that it deals with every conceivable error condition. The principle also involves performance in a network-friendly manner and drives the point home with specific verbiage, such as “be liberal in what you accept and conservative in what you send.”

To clarify, for applications that do not require reliable transport services, UDP is available. This is called a UDP/IP application, and it is distinct from TCP/IP.

The nuts and bolts of protocol operations exist as fields within the bit-level structure of each data unit, whether it is a frame, segment, or packet. According to the layered protocol discussion so far, those particular units, or chunks, of data will at some point exist within the same logical structure. The concept was described at a high level in the layered communications example earlier in this chapter (specifically at Step 4). At that point, application data and an application layer header—if required, an attribute that is unique to the application—were encapsulated inside an Ethernet header and trailer along with transport and Internet layer headers. The role of a TCP/IP protocol header is to convey information to the other layers and to its peer of the same protocol at the other end of the path. (This is the adjacent-layer and same-layer interactions, respectively.) Figure 1-5 shows application data encapsulated as an Ethernet frame, an IP packet, and a TCP segment.

Figure 1-5

Datagram encapsulation

A common vehicle for malicious network activity is an altered header field. Attackers capture all (or part) of a message so that it can be used for illegal purposes. The first line of defense is to know which headers are subject to legitimate change and which headers need to be fixed at a specific value, either because of protocol requirements or local security policies. The following list includes high-level categories for expected header behavior. Detailed IP header information is displayed later in this chapter:

• Inferred. Values that can be inferred from other values. An example is packet length.

• Static. Values in these fields are expected to be constant throughout the packet stream’s life; they must be communicated at least once. The IP version number is an example.

• Static-Def. Static fields whose values define a packet stream. IP source and destination addresses are in this classification.

• Static-Known. Static fields that are expected to have well-known values and do not need to be communicated, such as an IP version 4 (IPv4) header length field.

• Changing. These fields are expected to vary randomly within a limited value set or range; the TTL field is an example.

Internet Protocol

IP is a primary protocol of the OSI Model and, as its name suggests, an integral part of TCP/IP. Although the word Internet appears in its name, IP is not restricted to use on the global Internet, where it is implemented on all participating hosts. So, what’s in a name? Readers interested in Internet history may enjoy visiting one of several Web sites that the Internet Society sponsors. The society rests at the top of a loosely formed organization of engineers, researchers, operators, and visionaries from the academic community. The IETF is connected to that hierarchy and, through its working groups, keeps the Internet running and is involved in its continued evolution. The URL for the IETF site is https://www.ietf.org/.

Because it is connectionless and uses logical addressing, IP is easily ported to networks that are isolated from the Internet. It is an excellent choice for managers of enterprise networks who need efficient, machine-to-machine communications today, but must prepare for Internet connectivity tomorrow. As a practical matter, when compared with non-IP networks, an existing IP infrastructure is cheaper to migrate to the Internet or to an extranet2 connection with another organization. NetWare environments, where IPX is a competing protocol, face bigger challenges as the need for growth becomes a reality.

A key concept about IP is that it is a routed protocol, not a routing protocol. An IP packet knows where it is going in the network because it holds addressing information that is unique to its destination. Furthermore, it can only be destined for an IP host, which is termed as such because it contains an IP address. To reach that destination, the packet depends on a routing protocol to direct its path by creating routing tables in infrastructure devices (hence the term router). The dependency of routed protocols on routing protocols is only a small sample, albeit an important one, of a larger set of interactions between software entities that keep the electronic world connected.

IP serves two basic purposes: addressing and fragmentation. The protocol is rigidly structured, and the logical part of its addressing capabilities does not imply a logical or virtual circuit. Fragmentation and reassembly is used for traversing networks3 where transmission units are smaller than at the packet’s source.

Engineers who have supported Ethernet segments might have a better grasp of what connectionless means, at least in the context of TCP/IP. They learned quickly enough that, however voluminous the trouble calls were from first-level support personnel, collisions were generally a good thing. As a shared medium, Ethernet reported collisions when multiple hosts transmitted simultaneously, mainly so some would back off and wait in line to retransmit. Too many collisions were symptomatic of error conditions, but more often than not, there was no cause for alarm. Just as “management events” might have been a better term than “collisions,” connectionless is a better term than “unreliable” when discussing IP. One of the reasons that IP is a robust, efficient protocol is that it leaves time-consuming tasks, such as looking up addresses in routing tables, to resident modules in devices along its path. By design, it is not involved in connection establishment and has no flow-control mechanism. When reliable delivery is necessary, the connection-oriented, higher layer protocol, TCP, produces that service.

The closest thing to flow control in IP—and it is not close at all—is the TTL field in its header. The upper bound of the TTL value is set at the sending side, and it is decremented by one at each point along the route. If the value reaches zero before the packet reaches its destination, the packet is destroyed, which prevents an infinite routing loop. IP packets do not have a checksum function for the data contents of their payload; that’s only for header information.

IP provides for a maximum packet size of 65,535 octets, which is much larger than most networks can handle, hence the need for fragmentation. When the first fragment arrives at its destination, the receiving host’s Internet layer starts a reassembly timer; if all fragments are not received by the time a predetermined value is reached, the received fragments are discarded. When fragments are received on time, the receiving host uses the identification field in the IP header to ensure that fragments are inserted back into the correct packet.

This fragmentation method is called Internet fragmentation, and it is documented in the specification for the IP protocol. An intranet fragmentation method is in existence that might be implemented by software developers, but it is outside of RFC specifications. It is a LAN-only method that is transparent to the Internet module in host software.

Attackers can use altered fragments to allow incoming connections on outgoing-only ports. In 2001, this was exemplified by the Tiny Fragment Attack and the Overlapping Fragment Attack, both of which are explained in RFC 3138, “Protection Against a Variant of the Tiny Fragment Attack.” Do not confuse reassembling fragmented packets with situations where packets unexpectedly arrive out of order. Out-of-order packet arrival is symptomatic of one or more situations that are far more serious than a route through a small packet network. Some of the more worrisome causes for out-of-order packet arrival are

• Packets have been captured, tampered with, and then played back for intrusion or reconnaissance purposes. An example is a man-in-the-middle (MITM) attack (also called a replay attack).

• Asymmetric routing4 is occurring, which, under certain conditions, causes out-of-order packet arrival. For example, when the return path has changed because of a circuit failure and the new path has higher propagation delays, an increase in the overall round trip time (RTT) is experienced. This particular condition is known to cause out-of-order packet arrivals.

• Certain router load-sharing configurations, where the outbound packet stream splits across multiple interfaces, can cause out-of-order packet arrival at the destination.

The IPv4 header is specified in RFC 791, “Internet Protocol,” as being six 32-bit words in length when all optional fields are populated and with a minimum value of five words. It has no hardware dependencies and must be compatible with previous versions of IP. The requirement in RFC 791 for compatibility with earlier versions was important at the time because there had been six prior versions in production on ARPANET. This becomes relevant again as IP version 6 (IPv6) becomes a reality on the Internet. Figure 1-6 shows the IPv4 header layout.

Figure 1-6

IPv4 header layout

A more detailed explanation of an IP packet structure is expounded in the following list. The field name is followed by its length and description:

• Version Number (4 bits). Contains the IP version of the packet, which is how gateways along network paths know how to interpret data in the packet. If the version number is incorrect, the packet is silently discarded, which simply means that no error message is sent.

• Internet Header Length (IHL) (4 bits). Reflects the total length of the IP header built by the sending host. The unit of measure is defined in RFC 791, “Internet Protocol,” as 32-bit words. The minimum value is five.

• Differentiated Services (6 bits). Populated by the Type of Service parameter in the original specification, which has been updated by RFC 2474, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.” A further update, RFC 3168, “The Addition of Explicit Congestion Notification (ECN) to IP,” added Explicit Congestion Notification (ECN), which is the next entry in this list. Differentiated services enable service discrimination by mapping the Differentiated Services Codepoint (DSCP) to a value that changes the treatment of packets by routers in its path. This essentially changes the per hop behavior (PHB).

• Explicit Congestion Notification (ECN) (2 bits). The bits are used together to indicate any of the following status conditions:

• 00. Not ECN-Capable Transport (Not-ECT)

  01. ECN-Capable Transport (ECT 1)

  10. ECN-Capable Transport (ECT 0). This is the same as ECT 1; implementations may use either.

  11. Congestion Experienced (CE)

  Equipment manufacturers slowly adopted ECN, but it is now available in most IP devices as a configuration option. Its main benefit is that routers can actually send notifications of congestion instead of simply dropping packets.

• Total Length (16 bits).5 Indicates the total length of the datagram, including the header and data; the unit of measure is octets. The length of the data field can be computed by subtracting the Internet header length from this value. A recommendation is given in RFC 791, “Internet Protocol,” that hosts only send datagrams larger than 576 octets if there is assurance that the receiving end can accept large datagrams. The maximum Internet header length is 60 octets, although the most typical size is 20, which leaves ample room for a considerable amount of data. The liability of sending larger datagrams is that fragmentation can occur.

• Identification (16 bits). Holds an identifying value that is assigned by the sending host. This number is required when reassembling fragmented messages, which ensures that the fragments of one message are not intermixed with other messages.

• Flags (3 bits). Control flags used by the fragmentation process include the following:

• Bit position 0 is reserved and must be zero.

  Bit position 1 indicates either may fragment (0) or don’t fragment (1).

  Bit position 2 indicates last fragment (0) or more fragments (1).

• Fragment Offset (13 bits). Indicates where this fragment belongs in the datagram; it is measured in units of 8 octets. This enables IP to reassemble fragmented packets in the proper order.

• Time to Live (TTL) (8 bits). Also called the hop limit. Generally automatically set by the sender and is decremented by 1 at each hop during its journey to the destination node. If the value reaches zero before the datagram reaches its destination, the datagram, which is probably undeliverable anyway, is discarded. The purpose of the TTL field is to avoid the risk of eternal packets overwhelming the Internet.

• Protocol (8 bits). Identifies the next level protocol in the data portion of the Internet datagram as specified by the Internet Assigned Numbers Authority (IANA) in coordination with the IETF. A list used to be maintained in an RFC, but that was replaced by an online database at https://iana.org. Some examples include the following.

• Decimal	Keyword	Protocol	Reference
  0	HOPOPT	IPv6 Hop-by-Hop Option	RFC 1883
  1	ICMP	Internet Control Message	RFC 792
  2	IGMP	Internet Group Management	RFC 1112
  3	GGP	Gateway-to-Gateway	RFC 823
  4	IP	IP in IP (encapsulation)	RFC 2003
  5	ST	Stream	RFC 1190 and RFC 1819
  6	TCP	Transmission Control	RFC 793
  7	CBT	CBT	Tony Ballardie
  8	EGP	Exterior Gateway Protocol	RFC888 and David Mills

• Header Checksum (16 bits). Checksum for the header only. Because of changing header fields, such as the TTL value, the header checksum is recalculated and verified every time the Internet header is processed. The checksum algorithm takes the one’s complement, which negates negative numbers by inverting each bit in the number of the 16-bit sum of all 16-bit words. This is a fast, efficient algorithm, but it misses some unusual corruption circumstances, such as the loss of an entire 16-bit word that contains only 0s. However, because the data checksums used by both TCP and UDP cover the entire packet, these types of errors usually can be caught as the frame is assembled for the network transport.

• Source IP Address (32 bits). The IP addresses of the sending host.

• Destination IP Address (32 bits). The IP addresses of the receiving host.

• Options (variable length). A mandatory implementation for all IP hosts and gateways; transmission of the field is optional. There are two possible use cases:

• Case 1. One octet as option-type.

  Case 2. One octet as option-type; one octet as option-length; and a variable amount of option-data octets.

  The option-type octet has three fields that convey information:

  • One bit for the copied flag (0 = not copied; 1 = copied).

  • Two bits for the option class (0 = control; 1 = future use; 2 = debugging and measurement; 3 = future use).

  • Five bits for the option number.

  There are seven control class (0) options and one debugging and measurement (2) option, as shown in Table 1-6.

  Table 1-6 Options

  Class	Number	Length	Description
  0	0	—	End of option list. Occupies one octet and has no length octet.
  0	1	—	No operation. Occupies one octet and has no length octet.
  0	2	11	Security. Carries security, compartmentation,* user group, and handling restriction codes.
  0	3	Variable	Loose source routing. Routes datagrams based on information supplied by the source host. Allowed to use any route or number of intermediate gateways.
  0	9	Variable	Strict source routing. Allows no deviations from the specified route. If the route cannot be followed, the datagram is dropped. Strict routing is frequently used for testing routes, but rarely for transmission of user datagrams. This is because of the increased chances of the datagram being dropped.
  0	7	Variable	Record route. Used to trace the datagram route.
  0	8	4	Stream ID. Carries the stream identifier.
  2	4	Variable	Internet timestamp.

  *Defined by the Merriam-Webster Online Dictionary as “division into separate sections or units.”

• Padding (variable bits). Padding of zero values to ensure that the header ends on a 32-bit boundary.

Addressing

Moving datagrams through the Internet or through an enterprise network requires the use of three important protocol components: name, address, and route. A name describes the target host; an address identifies where the target is located, usually its physical or logical location in a network; and a route shows how to get there.

In many ways, network addresses are analogous to the addresses that the postal service uses to deliver mail. Both have standard addressing conventions that everyone must use; the source and destination is included, although the postal service is flexible in that regard; there are times when the payload they are associated with is lost along the way. Where networks are concerned, topology, which shows computers and the links between them, is the deciding factor for choosing the correct addressing convention. Topologies are formed over one or more of the following network types:

• Local area network (LAN). A link that operates mainly at the physical and data link layers. Examples of technologies are Ethernet, token ring, and FDDI.

• Wide area network (WAN). Can include multiple, connected point-to-point links (hops); switched virtual circuits (SVCs), where the communication link is shared by multiple hosts that switch on data transmission and then release the circuit for use by others; permanent virtual circuits (PVCs), where multiple hosts are each assigned and permanently use one logical slice of the same communications link; Integrated Services Digital Network (ISDN), which is a telecommunications technology that carries voice, data, and video; and other physical media types. WAN operates at all TCP/IP and OSI Model layers or a subset thereof. Example technologies are HDLC, synchronous data link control (SDLC), Frame Relay, Asynchronous Transfer Mode (ATM), Frame Relay-to-ATM service interworking; and the Internet.

• Metropolitan area network (MAN). Extends LAN capabilities to a geographic area that is the size of an average U.S. city. Operates mainly at the physical and data link layers, but with more instances of network layer operations than on most LANs. Examples are Ethernet, token ring, FDDI, and switched multimegabit data service (SMDS). Builders of MANs frequently take advantage of dark fiber, which are fiber-optic transmission facilities that are not in operation and were once installed for future use.

• Mobile ad-hoc network (MANET). Leverages wireless, satellite, and radio communications to create a network that is literally mobile. Many law enforcement and military applications have this type of network.

Addresses are either physical, which means that they are hard-coded in the equipment, or logical. Because they are not hard-coded, logical addresses can be changed through a software-configuration process. IP uses logical addressing.

Unlike logical addresses, physical addresses cannot be seen beyond the boundary of the connected link. Routing does not occur at this layer because it forwards frames based on Layer 2 header information. One way to view the concept is to compare troubleshooting scenarios for each technology. Analyzing traffic on a Layer 3 link means that there might be multiple hops involved and that the end-to-end path could enter and exit multiple devices; a diagram of each hop, or point, would be labeled point A to point B to point C, and so forth, depending on the number of hops; the same work on a Layer 2 link is limited to point A to point B.

In OSI Model terminology, the physical address is called the Media Access Control (MAC) address. It is a data link layer function, not a physical layer function as the name might imply. The data link layer is subdivided into a logical link control (LLC) sublayer and the MAC sublayer. LLC and MAC addresses are administered under the authority of the IEEE.

The length of the physical address varies according to the networking system, but Ethernet and several others use 48 bits. For communication to occur, two addresses are required: one each for the sending and receiving devices. The IEEE assigns a 24-bit organization unique identifier (OUI) so that organizations can assign the remaining 24 bits to suit their unique needs. Two of the 24 bits assigned as an OUI are control bits. The IEEE Ethernet and allied standards use another address for link service access points (LSAPs), which provide services to Layer 3 protocols.

IP Addresses

TCP/IP within the IPv4 format uses a 32-bit address to identify a machine on a network and the network to which it is attached. IP addresses identify a machine’s connection to the network, not the machine itself. The IP address is the set of numbers that many people see on their workstations, such as 127.40.8.72, which uniquely identifies the device. When such a device is connected to the Internet, as opposed to a closed enterprise, it is at the bottom of a global hierarchy for address assignments. End users “rent” an IP address from their Internet Service Provider (ISP), who receives address assignments from a global network of authoritative registries, whose protocol-related operations are coordinated by IANA. Registry organizations can be a Local Internet Registry (LIR), Regional Internet Registry (RIR), or National Internet Registry (NIR). The list of current registries and their areas of coverage is as follows:

• AfriNIC. Africa region.

• APNIC. Asia/Pacific region.

• ARIN. North America region.

• LACNIC. Latin America and certain Caribbean islands.

• RIPE NCC. Europe, Middle East, and Central Asia.

Of the, two available IP protocol versions—IPv4 and IPv6—IPv4 is by far the most widely used today. It was originally organized into classes:

• Class A (0.0.0.0 to 127.255.255.255) for general use. Class A addresses are for large networks; they use 8 bits for the network ID and 24 bits for the host ID.

• Class B (128.0.0.0 to 191.255.255.255) for general use. Class B addresses are for intermediate networks; they use 16-bit host addresses and 16-bit network addresses.

• Class C (192.0.0.0 to 223.255.255.255) for general use. Class C addresses have only 8 bits for the host address, limiting the number of devices to 256. There are 24 bits for the network address.

• Class D (224.0.0.0 to 239.255.255.255) multicast. Class D is for multicast purposes only; the manner of operation is that each multicast address represents a particular group of hosts. IANA assigns permanent addresses and allocates transient addresses through the network of registries.

• Class E (240.0.0.0 to 255.255.255.255) reserved. Class E addresses have historically been reserved for use by the IETF for experimental purposes, but IANA is currently in the process of changing the designation to private use. At the time of writing, it is unclear what private use means in this context, but it is likely that this is a stopgap measure to avoid running out of addresses while the world waits for IPv6.

Certain blocks of addresses within the available spaces are reserved for private Internets. For example, the Class C range (192.168.0.0 to 192.168.255.255) is available and is what many ISP customers see on their computers in their home network.

Classes A, B, and C are most germane to this discussion, particularly as a foundation for understanding Classless Inter-Domain Routing (CIDR), which is discussed at the end of this section. Readers can see that the classful addressing scheme that has served the Internet so well in past decades is virtually slipping away without notice. It is now officially considered as having a “historic” status.

The term classful addressing comes from the fact that a specific number of bits assign an address to a class, and there are different combinations of possible networks and hosts according to each one. The design accommodates the unique networking requirements of organizations by offering options that match their own distributed computing environment. For example, a national sales force with small operations in 1,000 cities needs a lot of network addresses, but few host addresses. That is how it connects teams of only five or six employees to the rest of the company. Centralized business operations, on the other hand, require the opposite—a lot of host addresses and few network addresses. Table 1-7 summarizes classful network addresses for general-purpose classes.

Table 1-7 Classful Network Addressing

Host IDs with all 0s and all 1s cannot be assigned, which reduces the number of possible hosts by two.

Class A network ID numbers 0 and 127 are reserved, so 2 bits are subtracted in calculations.

Because even centralized operations, where most of the company’s workforce is in the same city, might need a campus network, classful addressing can subdivide a single network into several smaller ones, called subnetworks. Subnetting is accomplished by using subnet masks to change the meaning of an IP address. The subnet mask defines the network and host bits in an associated address and is one way to tell, at a glance, which class is in use. Table 1-8 shows the default masks in both dotted-decimal form and their full binary equivalents. It is customary to use a single zero in the dotted-decimal form to represent eight zeros in an octet.

Table 1-8 Subnet Mask translation

A visual inspection of the masks shown here, along with the total network ID bits in Table 1-7, reveals that bit positions populated by ones align with the network ID. The reverse of that is true and is shown in the number of possible hosts. What is not implicit in the visual part of the scheme is the fact that changes to a subnet mask can increase/decrease the number of hosts, but not the possible number of networks.

The following example uses a Class B subnet mask, where

• n = a decimal position in the network octet

• x = a decimal position in the host octet

                                                Dotted Decimal             Binary
Default Class B network mask:                   255.255.0.0                1111111.11111111.00000000.00000000
Network and host octets:                        nnn.nnn.x.x

Modifications to the mask affect the address as follows:

Modified Class B network mask:                255.255.224.0                11111111.11111111.11100000.00000000
Network, subnet, and host octets:             nnn.nnn.x.x                  11111111.11111111.00000000.00000000

The network and host octets do not change because this is still a Class B address according to the old classful addressing system. The change must be represented differently:

Address with default Class B mask:    , 
Address with new subnet mask:         , , 

This form of notation is used in, among other documents, RFC 1812,6 “Requirements for IP Version 4 Routers,” where the rules are laid out for the use of this historical scheme in a CIDR environment. CIDR addressing uses the length/prefix notation for addresses where the prefix represented the number of bits in a subnet mask, but now, it is part of the official convention for addressing. A CIDR address is described as

IP address = , 

In router configurations = n.n.0.0/16

This CIDR naming convention looks exactly like what the legacy Class B mask would be if it were written as such, but it is not a Class B address. Subnetting allows users to get more out of their assigned address space within their own network. Devices with Internet connectivity need to use only those addresses that are in the range and assigned by their local registry.

The lengths of each section of the IP address were carefully chosen to provide maximum flexibility in assigning both network and local addresses. The total length is fixed at 32 bits and is divided into four octets according to the notation used to type the address on a keyboard or write it on paper. To put that description in context, here is a basic example of how an IP address translates from four octets—as people see them—to the 1s and 0s that machines can read. This example uses a common internal IP address.

An IP address written as four octets looks like this:

192.168.1.101

Figure 1-7 shows a way to convert this IP address without a calculator or conversion chart.

Figure 1-7

Quick conversion of an IP address from octets to bits

To use this shortcut by hand, write the address’ decimal version on paper and leave room in between each for the values underneath. Because each decimal value represents an octet, 8-bit positions are populated in the next line, as Figure 1-7 shows. The last step is to add whichever numbers from the 8-bit positions equal the decimal value; fill in 1s underneath those values and 0s underneath those that were not used. The result is a 32-bit binary representation of the IP address.

From the IP address, a network can determine if the data will be sent out through a gateway. If the network address is the same as the current address (routing to a local network device, called a direct host), the gateway is avoided, but all other network addresses are routed to a gateway to leave the local network (indirect host). The gateway receiving the data to transmit to another network must then determine the routing from the data’s IP address and an internal table that provides routing information.

If an address is set to all 1s, it applies to all addresses on the network, so an IP address of 32 1s is considered a broadcast message to all networks and all devices. It is possible to broadcast to all machines in a network by altering the local or host address to all 1s so that the address 147.10.255.255 for a Class B network is received by all devices. Coding the address as all 0s refers only to the originating device. The all-zero format is used when the network IP address is not known, but other devices on the network can still interpret the local address. By convention, no local device is given a physical address of 0. It is possible for a device to have more than one IP address if it is connected to more than one network, as is the case with gateways. This is sometimes referred to as being multihomed.

The address 127.0.0.1 is reserved as the loopback address of a device. It is used for test purposes and cannot be assigned as a host ID, but here is a way to configure additional loopback addresses on a router for network-management purposes. Consider a router that has eight interfaces, all of which have a unique IP address. Remote network management systems (NMS) need a target address to reach the router in order to query its MIB. The address used is fundamentally just an open door for the NMS to collect MIB tables regarding the entire router, not just the interface associated with the address. If the circuit is down for the interface that happens to have the target address, data collection is interrupted. Most router vendors offer the capability to configure a virtual interface, using any valid IP address, as a loopback interface for network-management purposes. The main benefit is that it is available as long as the router is operational.

IPv6

IP version 6 (IPv6) was designed to address the issues inherent to IPv4. The major improvement with IPv6 is the capability to handle much larger address spaces, which eliminates any threat of running out of IP addresses. In addition to scalability, IPv6 offers improved security, ease of configuration, and network management. It has been tested on a worldwide, isolated network called 6BONE, which included participants in more than 30 countries.

The major changes brought about by IPv6 are as follows:

• Greater address space. The address space in IPv6 is 128 bits long, compared to IPv4’s 32 bits.

• Stateless addressing. IPv6 networks can automatically route messages using the ICMPv6 discovery messages that send a broadcast to other routers with details of its network.

• Link local address. Automatically configured in the host; valid only in the local physical link.

• Large packet support. Enables packets up to 4GB instead of IPv4’s limit of 64KB.

• Streamlined header that moves nonessential and optional fields to extension headers for increased efficiency in processing at intermediate nodes.

IPv6 addresses are usually written as eight groups of four hexadecimal digits separated by colons. So, if an IPv4 address is 205.154.89.200, an IPv6 address looks like 192a:0d8e:743b:92f2:a083:cf3e:6fe4:8237.

According to specifications in RFC 4292, “IPv6 Addressing Architecture,” long strings of 0s can be compressed using the special syntax ::, as long as it appears only once in an address. The double-colon syntax can also be used for leading or trailing 0s.

Figure 1-8 shows what the IPv6 header looks like.

Figure 1-8

IPv6 header

The header itself is 320 bits long (40 octets) and contains the following:

• Version. 4-bit IP version

• Traffic class. A packet priority value

• Flow label. Used for quality of service (QoS) management (currently unused)

• Payload length. Number of bytes in the payload

• Next header. Next encapsulated protocol (compatible with IPv4 values)

• Hop length. TTL value from IPv4

• Source address. 128-bit IPv6 address

• Destination address. 128-bit IPv6 address

IPv6 was developed in the early 1990s. It was supposed to roll out in the late 1990s, but this never happened because of the differences in IPv4 and IPv6 and the cost of simultaneously supporting both protocols. IPv6 has been added as a viable protocol for the Internet only in the last two years, with full support along the backbone for IPv6 now in place. Although plans to phase out IPv4 in favor of IPv6 are touted, the sheer number of legacy devices that cannot support IPv6 means that a complete switchover is unlikely to happen for many years. Conversion efforts might be hastened by the U.S. Office of Management and Budget (OMB), which mandated that federal agencies convert to IPv6 by June 30, 2008. The 26 agencies in the mandate all made the deadline in some manner.

Summary

Since its official birth in 1983, the Internet has grown beyond its fashionable description as the information superhighway to a communication mechanism that is a necessity, not just a convenience. Government and commercial entities depend on its services when it is necessary to communicate with people not part of their own isolated and secure networks. The Internet is so critical to global concerns that virtually every developed country in the world now has a hand in its continued evolution. The layered set of protocols that make it work enable innovation in many forms, and technical contributions are never in short supply.

Commercial and government enterprises, those networks that are isolated from public network connectivity, mirror the Internet in many ways. Layer 2 switching technologies on the LAN connect to Layer 3 routers in a way that enables personal computers, servers, printers, and various video and voice devices to connect on a global scale.

In the midst of such extensive global communication, a constant struggle against illegal activities exists. Network security professionals must participate in every aspect of network innovation, either as inventors or as students of technology.

---

Footnotes

1.  The word gateway references functionality, not a special type of device. In TCP/IP terms, gateway and router describe devices at hops in the routed path. The OSI Model equivalent is intermediate system (IS).

2.  Extranet describes limited network connectivity, perhaps a single link, between autonomous companies or agencies.

3.  Remember that the Internet is a network of networks.

4.  Asymmetric routing is when a packet takes a different path on the inbound side of a link than it took on the outbound side.

5.  In keeping with the rest of the list, this is the number of bit positions taken by the Total Length field. It should not be confused with the associated description.

6.  The term used in RFC 1812 for this addressing scheme is “classical.” The word “classful” came after the RFC was authored.

---

© Copyright Pearson Education. All rights reserved.