This paper looks at the basic structure of TCP/IP, the driving force behind almost all networks in use today, as well as how TCP/IP functions on a network level. The paper starts with a look at the design of TCP/IP as a layered architecture, based on the OSI model of specific-purpose layers, and how TCP/IP fits into the OSI model. It wraps up with a look at the IP structure, because understanding how IP packets are formed will help you understand how data moves around a network.
To help differentiate the many tasks TCP/IP has to perform, and to allow for a logical separation of design, TCP/IP uses a layered model based on the OSI (Open Systems Interconnect) layered model. The layers of the OSI architecture are meant to be stand-alone, independent entities (and although they cannot perform any observable task without interacting with other layers, from a programming point of view they can be treated as self-contained).
The OSI Reference Model (OSI-RM) uses seven layers. The TCP/IP architecture is similar but involves only five layers. It’s worth looking at the OSI layered model first in a little detail to explain what the layers are supposed to be doing. The seven layers are (from top to bottom):
The application, presentation, and session layers are all application-oriented in that they are responsible for presenting the application interface to the user. All three are independent of the layers below them and are totally oblivious to the means by which data gets to the application. These three layers are called the upper layers.
The lower four layers deal with the transmission of data, covering the packaging, routing, verification, and transmission of each data group. The lower layers don't worry about the type of data they receive or send to the application, but deal only with the task of sending it. They don't differentiate between the different applications in any way. The real world treats the data link layer and the physical layer as one combined layer, but the formal OSI definition stipulates different purposes for each.
TCP/IP was designed with layers, although they do not correspond one-to-one with the OSI-RM layers. The differences between the OSI architecture and that of TCP/IP relate to the layers above the transport level and those at the network level. OSI has both the session layer and the presentation layer, whereas TCP/IP combines both into an application layer. The requirement for a connectionless protocol also required TCP/IP to combine OSI's physical layer and data link layer into a network level. TCP/IP also includes the session and presentation layers of the OSI model into TCP/IP’s application layer.
At the start, a fuss was made about the network level combination, although the argument was mostly academic, as most implementations of the OSI model combined the physical and link levels on an intelligent controller (such as a network card) anyway. The combination of the two layers into a single layer had one major benefit: it enabled a subnetwork to be designed that was independent of any network protocols, because TCP/IP was oblivious to the details.
The layered approach in fact gave rise to the name TCP/IP. The transport layer uses the Transmission Control Protocol (or one of several variants, such as the User Datagram Protocol). There is, however, only one protocol for the network level, the Internet Protocol (IP).
TCP/IP is not involved in the bottom two layers of the OSI model (data link and physical) but begins in the network layer, where the Internet Protocol (IP) resides. In the transport layer, the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are involved. Above this, the utilities and protocols that make up the rest of the TCP/IP suite are built using the TCP or UDP and IP layers for their communications system.
TCP/IP is not a single (or even two) protocols, but a collection of protocols that build on IP and TCP or UDP. It’s worth taking a quick look at the family’s more well-known members:
Telnet provides a remote login capability. This lets a user on one machine log onto another machine and act as though he or she were directly in front of the second machine.
File Transfer Protocol enables a file on one system to be copied to another system. The user doesn't actually log in as a full user to the machine he or she wants to access, as with Telnet, but instead uses the FTP program to enable access.
Simple Mail Transfer Protocol is used for transferring electronic mail. SMTP is completely transparent to the user. Behind the scenes, SMTP connects to remote machines and transfers mail messages much like FTP transfers files.
Kerberos is a widely supported security protocol. Kerberos uses a special application called an authentication server to validate passwords and encryption schemes.
Domain Name System enables a computer with a common name to be converted to a special network address. DNS provides a conversion from the common local name to the unique physical address of the device's network connection.
Simple Network Management Protocol provides status messages and problem reports across a network to an administrator. SNMP uses User Datagram Protocol (UDP) as a transport mechanism.
Network File System is a set of protocols developed by Sun Microsystems to enable multiple machines to access each other's directories transparently. They accomplish this by using a distributed file system scheme.
Remote Procedure Call is a set of functions that enable an application to communicate with another machine (the server). It provides for programming functions, return codes, and predefined variables to support distributed computing.
Trivial File Transfer Protocol is a very simple, unsophisticated file transfer protocol that lacks security. It uses UDP as a transport. TFTP performs the same task as FTP, but uses a different transport protocol.
Transmission Control Protocol (the TCP part of TCP/IP) is a communications protocol that provides reliable transfer of data. It is responsible for assembling data passed from higher-layer applications into standard packets and ensuring that the data is transferred correctly.
User Datagram Protocol (UDP) is a connectionless-oriented protocol, meaning that it does not provide for the retransmission of datagrams (unlike TCP, which is connection-oriented). UDP is not very reliable, but it does have specialized purposes.
Internet Protocol is responsible for moving the packets of data assembled by either TCP or UDP across networks. It uses a set of unique addresses for every device on the network to determine routing and destinations.
Internet Control Message Protocol is responsible for checking and generating messages on the status of devices on a network. It can be used to inform other devices of a failure in one particular machine.
Most networks, including the Internet, can be thought of as a layered architecture. It is convenient to think of the Internet as having four layers. These layers should not be confused with the architecture of each machine, as described in the OSI seven-layer model. Instead, they are a method of seeing how the internetwork, network, TCP/IP, and individual devices work together:
· Independent devices reside in the subnetwork layer at the bottom of the architecture, connected together in a network (a LAN) which is called a subnetwork.
· On top of the subnetwork layer is the internetwork layer, which provides the functionality for communications between networks through gateways. Each subnetwork uses gateways to connect to the other subnetworks in the internetwork. The internetwork layer is where data gets transferred from gateway to gateway until it reaches its destination and then passes into the subnetwork layer. The internetwork layer runs the Internet Protocol (IP).
· The service provider protocol layer is responsible for the overall end-to-end communications of the network. This is the layer that runs the Transmission Control Protocol (TCP) and other protocols. It handles the data traffic flow itself and ensures reliability for the message transfer.
· The top layer is the application services layer, which supports the interfaces to the user applications.
A simple example shows how this architecture model works. Assume that an application on one machine wants to transfer data (encapsulated in a datagram) to an application on another machine in a different subnetwork. Ignoring the messages between layers, and simplifying the architecture a little, the process is:
Network addresses are analogous to mailing addresses in that they tell a system where to deliver a datagram. Three terms commonly used in the Internet relate to addressing: name, address, and route. The term address is often generically used with communications protocols to refer to many different things. It can mean the destination, a port of a machine, a memory location, an application, and more. A name is a specific identification of a machine, a user, or an application. It is usually unique and provides an absolute target for the datagram. An address typically identifies where the target is located, usually its physical or logical location in a network. A route tells the system how to get a datagram to the address.
From a name, a network software package called the name server tries to resolve the address and the route. When you send electronic mail, you simply indicate the recipient's name, relying on the name server to figure out how to get the mail message to them.
Using a name server has one other primary advantage besides making the addressing and routing unimportant to the end user: It gives the system or network administrator a lot of freedom to change the network as required, without having to tell each user's machine about any changes. As long as an application can access the name server, any routing changes can be ignored by the application and users.
There are several types of addressing, including the LAN system, as well as the wider internetwork addressing conventions:
· Subnetwork Addressing: On a single network, several pieces of information are necessary to ensure the correct delivery of data. The primary components are the physical address and the data link address.
· The Physical Address: Each device on a network that communicates with others has a unique physical address, sometimes called the hardware address. On any given network, there is only one occurrence of each address; otherwise, the name server has no way of identifying the target device unambiguously. For hardware, the addresses are usually encoded into a network interface card, set either by switches or by software. With respect to the OSI model, the address is located in the physical layer.
The length of the physical address varies depending on the networking system, but Ethernet and several others use 48 bits in each address. For communication to occur, two addresses are required: one each for the sending and receiving devices. For each subnetwork, the IEEE assigns an organization unique identifier (OUI) that is 24 bits long, enabling the organization to assign the other 24 bits however it wants. (Actually, two of the 24 bits assigned as an OUI are control bits, so only 22 bits identify the subnetwork.)
The combination of 24 bits from the OUI and 24 locally assigned bits is called a media access control (MAC) address. When a packet of data is assembled for transfer across an internetwork, there are two sets of MACs: one from the sending machine and one for the receiving machine.
· The Data Link Address: The IEEE Ethernet standards (and several other allied standards) use another address called the link layer address (abbreviated as LSAP for link service access point). The LSAP identifies the type of link protocol used in the data link layer. As with the physical address, a datagram carries both sending and receiving LSAPs. The IEEE also enables a code that identifies the EtherType assignment, which identifies the upper layer protocol (ULP) running on the network (almost always a LAN).
· Ethernet Frames: The layout of information in each transmitted packet of data differs depending on the protocol, but it is helpful to examine one to see how the addresses and related information are prepended to the data. This section uses the Ethernet system as an example because of its wide use with TCP/IP. It is quite similar to other systems as well.
An Ethernet frame is made up of several parts. The preamble is a set of bits that are used primarily to synchronize the communication process and account for any random noise in the first few bits that are sent. At the end of the preamble is a sequence of bits that are the start frame delimiter (SFD), which indicates that the frame follows immediately. The recipient and sender addresses follow in IEEE 48-bit format, followed by a 16-bit type indicator that is used to identify the protocol. The data follows the type indicator. The Data field is between 46 and 1,500 bytes in length. If the data is less than 46 bytes, it is padded with 0s until it is 46 bytes long. Any padding is not counted in the calculations of the data field's total length, which is used in one part of the IP header. At the end of the frame is the cyclic redundancy check (CRC) count, which is used to ensure that the frame's contents have not been modified during the transmission process.
· IP Addresses: TCP/IP 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. Whenever a machine's location on the network changes, the IP address must be changed, too. The IP address is the set of numbers many people see on their workstations or terminals, such as 127.40.8.72, which uniquely identifies the device.
IP (or Internet) addresses are assigned only by the Network Information Center (NIC), although if a network is not connected to the Internet, that network can determine its own numbering. For all Internet accesses, the IP address must be registered with the NIC.
There are four formats for the IP address, with each used depending on the size of the network. The four formats are called Class A through Class D. The class is identified by the first few bit sequences, one bit for Class A and up to four bits for Class D. The class can be determined from the first three (high-order) bits. In fact, in most cases, the first two bits are enough, because there are few Class D networks.
Class A addresses are for large networks that have many machines. The 24 bits for the local address (also frequently called the host address) are needed in these cases. The network address is kept to 7 bits, which limits the number of networks that can be identified. Class B addresses are for intermediate networks, with 16-bit local or host addresses and 14-bit network addresses. Class C networks have only 8 bits for the local or host address, limiting the number of devices to 256. There are 21 bits for the network address. Finally, Class D networks are used for multicasting purposes, when a general broadcast to more than one device is required. The lengths of each section of the IP address have been carefully chosen to provide maximum flexibility in assigning both network and local addresses.
IP addresses are four sets of 8 bits, for a total 32 bits. You often represent these bits as separated by a period for convenience, so the IP address format can be thought of as network.local.local.local for Class A or network.network.network.local for Class C. The IP addresses are usually written out in their decimal equivalents, instead of the long binary strings. This is the familiar host address number that network users are used to seeing, such as 126.96.36.199, which would indicate that the network address is 147.10 and the local or host address is 13.28. Of course, the actual address is a set of 1s and 0s. The decimal notation used for IP addresses is properly called dotted quad notation.
From the IP address, a network can determine if the data is to 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 data to be transmitted to another network must then determine the routing from the data's IP address and an internal table that provides routing information.
As mentioned, if an address is set to all 1s, the address applies to all addresses on the network. The same rule applies to IP addresses, so that 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 188.8.131.52 for a Class B network (identified as network 147.10) would be received by all devices on that network (255.255 being the local addresses composed of all 1s), but the data would not leave the network.
A slight twist is coding the network address as all 0s, which means the originating network or the local address being set to 0s, which refers to the originating device only (usually used only when a device is trying to determine its IP address). The all-zero network address 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. These devices are called multihomed, because they have a unique address for each network they are connected to. In practice, it is best to have a dedicate machine for a multihomed gateway; otherwise, the applications on that machine can get confused as to which address they should use when building datagrams.
Two networks can have the same network address if they are connected by a gateway. This can cause problems for addressing, because the gateway must be able to differentiate which network the physical address is on.
The Internet Protocol (IP) is a primary protocol of the OSI model, as well as an integral part of TCP/IP (as the name suggests). Although the word "Internet" appears in the protocol's name, it is not restricted to use with the Internet. It is true that all machines on the Internet can use or understand IP, but IP can also be used on dedicated networks that have no relation to the Internet at all. IP defines a protocol, not a connection. Indeed, IP is a very good choice for any network that needs an efficient protocol for machine-to-machine communications, although it faces some competition from protocols like Novell NetWare's IPX on small to medium local area networks that use NetWare as a PC server operating system.
Its main tasks are addressing of datagrams of information between computers and managing the fragmentation process of these datagrams. The protocol has a formal definition of the layout of a datagram of information and the formation of a header composed of information about the datagram. IP is responsible for the routing of a datagram, determining where it will be sent, and devising alternate routes in case of problems.
Another important aspect of IP's purpose has to do with unreliable delivery of a datagram. Unreliable in the IP sense means that the delivery of the datagram is not guaranteed, because it can get delayed, misrouted, or mangled in the breakdown and reassembly of message fragments. IP has nothing to do with flow control or reliability: there is no inherent capability to verify that a sent message is correctly received. IP does not have a checksum for the data contents of a datagram, only for the header information. The verification and flow control tasks are left to other components in the layer model. (For that matter, IP doesn't even properly handle the forwarding of datagrams. IP can make a guess as to the best routing to move a datagram to the next node along a path, but it does not inherently verify that the chosen path is the fastest or most efficient route.) Part of the IP system defines how gateways manage datagrams, how and when they should produce error messages, and how to recover from problems that might arise.
IP provides for a maximum packet size of 65,535 bytes, which is much larger than most networks can handle, hence the need for fragmentation. IP has the capability to automatically divide a datagram of information into smaller datagrams if necessary. When the first datagram of a larger message that has been divided into fragments arrives at the destination, a reassembly timer is started by the receiving machine's IP layer. If all the pieces of the entire datagram are not received when the timer reaches a predetermined value, all the datagrams that have been received are discarded. The receiving machine knows the order in which the pieces are to be reassembled because of a field in the IP header. One consequence of this process is that a fragmented message has a lower chance of arrival than an unfragmented message, which is why most applications try to avoid fragmentation whenever possible.
IP is connectionless, meaning that it doesn't worry about which nodes a datagram passes through along the path, or even at which machines the datagram starts and ends. This information is in the header, but the process of analyzing and passing on a datagram has nothing to do with IP analyzing the sending and receiving IP addresses. IP handles the addressing of a datagram with the full 32-bit Internet address, even though the transport protocol addresses use 8 bits. The newer version of IP, called IPv6, can handle much larger headers."
The datagram is the transfer unit used by IP, sometimes more specifically called an Internet datagram, or IP datagram. The specifications that define IP (as well as most of the other protocols and services in the TCP/IP family of protocols) define headers and tails in terms of words, where a word is 32 bits. Some operating systems use a different word length, although 32 bits per word is the more-often encountered value (some minicomputers and larger systems use 64 bits per word, for example). There are eight bits to a byte, so a 32-bit word is the same as four bytes on most systems.
The IP header is six 32-bit words in length (24 bytes total) when all the optional fields are included in the header. The shortest header allowed by IP uses five words (20 bytes total). To understand all the fields in the header, it is useful to remember that IP has no hardware dependence but must account for all versions of IP software it can encounter (providing full backward-compatibility with previous versions of IP). The IP header consists of:
Version Number: This is a 4-bit field that contains the IP version number the protocol software is using. The version number is required so that receiving IP software knows how to decode the rest of the header, which changes with each new release of the IP standards. Part of the protocol definition stipulates that the receiving software must first check the version number of incoming datagrams before proceeding to analyze the rest of the header and encapsulated data. If the software cannot handle the version used to build the datagram, the receiving machine's IP layer rejects the datagram and ignores the contents completely.
Header Length: This 4-bit field reflects the total length of the IP header built by the sending machine; it is specified in 32-bit words. The shortest header is five words (20 bytes), but the use of optional fields can increase the header size to its maximum of six words (24 bytes). To properly decode the header, IP must know when the header ends and the data begins, which is why this field is included. (There is no start-of-data marker to show where the data in the datagram begins. Instead, the header length is used to compute an offset from the start of the IP header to give the start of the data block.)
Type of Service: The 8-bit (1 byte) Service Type field instructs IP how to process the datagram properly. The first 3 bits indicate the datagram's precedence, with a value from 0 (normal) through 7 (network control). The higher the number, the more important the datagram and, in theory at least, the faster the datagram should be routed to its destination. In practice, though, most implementations of TCP/IP and practically all hardware that uses TCP/IP ignores this field, treating all datagrams with the same priority. The next three bits are 1-bit flags that control the delay, throughput, and reliability of the datagram. If the bit is set to 0, the setting is normal. A bit set to 1 implies low delay, high throughput, and high reliability for the respective flags. The last two bits of the field are not used. Most of these bits are ignored by current IP implementations, and all datagrams are treated with the same delay, throughput, and reliability settings. For most purposes, the values of all the bits in the Service Type field are set to 0 because differences in precedence, delay, throughput, and reliability between machines are virtually nonexistent unless a special network has been established.
Datagram Length (or Packet Length): This field gives the total length of the datagram, including the header, in bytes. The length of the data area itself can be computed by subtracting the header length from this value. The size of the total datagram length field is 16 bits, hence the 65,535 bytes maximum length of a datagram (including the header). This field is used to determine the length value to be passed to the transport protocol to set the total frame length.
Identification: This field holds a number that is a unique identifier created by the sending node. This number is required when reassembling fragmented messages, ensuring that the fragments of one message are not intermixed with others. Each chunk of data received by the IP layer from a higher protocol layer is assigned one of these identification numbers when the data arrives. If a datagram is fragmented, each fragment has the same identification number.
Flags: The Flags field is a 3-bit field, the first bit of which is left unused (it is ignored by the protocol and usually has no value written to it). The remaining two bits are dedicated to flags called DF (Don't Fragment) and MF (More Fragments), which control the handling of the datagrams when fragmentation is desirable. If the DF flag is set to 1, the datagram cannot be fragmented under any circumstances. If the current IP layer software cannot send the datagram on to another machine without fragmenting it, and this bit is set to 1, the datagram is discarded and an error message is sent back to the sending device.If the MF flag is set to 1, the current datagram is followed by more packets (sometimes called subpackets), which must be reassembled to re-create the full message. The last fragment that is sent as part of a larger message has its MF flag set to 0 (off) so that the receiving device knows when to stop waiting for datagrams. Because the order of the fragments' arrival might not correspond to the order in which they were sent, the MF flag is used in conjunction with the Fragment Offset field (the next field in the IP header) to indicate to the receiving machine the full extent of the message.
Fragment Offset: If the MF (More Fragments) flag bit is set to 1 (indicating fragmentation of a larger datagram), the fragment offset contains the position in the complete message of the submessage contained within the current datagram. This enables IP to reassemble fragmented packets in the proper order. Offsets are always given relative to the beginning of the message. This is a 13-bit field, so offsets are calculated in units of 8 bytes, corresponding to the maximum packet length of 65,535 bytes. Using the identification number to indicate which message a receiving datagram belongs to, the IP layer on a receiving machine can then use the fragment offset to reassemble the entire message.
Time to Live (TTL): This field gives the amount of time in seconds that a datagram can remain on the network before it is discarded. This is set by the sending node when the datagram is assembled. Usually the TTL field is set to 15 or 30 seconds. The TCP/IP standards stipulate that the TTL field must be decreased by at least one second for each node that processes the packet, even if the processing time is less than one second. Also, when a datagram is received by a gateway, the arrival time is tagged so that if the datagram must wait to be processed, that time counts against its TTL. Hence, if a gateway is particularly overloaded and can't get to the datagram in short order, the TTL timer can expire while awaiting processing, and the datagram is abandoned. If the TTL field reaches 0, the datagram must be discarded by the current node, but a message is sent back to the sending machine when the packet is dropped. The sending machine can then resend the datagram. The rules governing the TTL field are designed to prevent IP packets from endlessly circulating through networks.
Transport Protocol: This field holds the identification number of the transport protocol to which the packet has been handed. The numbers are defined by the Network Information Center (NIC), which governs the Internet. There are currently about 50 protocols defined and assigned a transport protocol number. The two most important protocols are ICMP, which is number 1, and TCP, which is number 6.
Header Checksum: The number in this field of the IP header is a checksum for the protocol header field (but not the data fields) to enable faster processing. Because the Time to Live (TTL) field is decremented at each node, the checksum also changes with every machine the datagram passes through. The checksum algorithm takes the ones-complement 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.
Sending Address and Destination Address: These fields contain the 32-bit IP addresses of the sending and destination devices. These fields are established when the datagram is created and are not altered during the routing.
Options: The Options field is optional, composed of several codes of variable length. If more than one option is used in the datagram, the options appear consecutively in the IP header. All the options are controlled by a byte that is usually divided into three fields: a 1-bit copy flag, a 2-bit option class, and a 5-bit option number. The copy flag is used to stipulate how the option is handled when fragmentation is necessary in a gateway. When the bit is set to 0, the option should be copied to the first datagram but not subsequent ones. If the bit is set to 1, the option is copied to all the datagrams. The option class and option number indicate the type of option and its particular value. At present, there are only two option classes set. (With only 2 bits to work with in the field, a maximum of four options could be set.) When the value is 0, the option applies to datagram or network control. A value of 2 means the option is for debugging or administration purposes. Values of 1 and 3 are unused.
There are two kinds of routing indicated within the Options field: loose and strict. Loose routing provides a series of IP addresses that the machine must pass through, but it enables any route to be used to get to each of these addresses (usually gateways). Strict routing enables no deviations from the specified route. If the route can't be followed, the datagram is abandoned. Strict routing is frequently used for testing routes but rarely for transmission of user datagrams because of the higher chances of the datagram being lost or abandoned.
Padding: The content of the padding area depends on the options selected. The padding is usually used to ensure that the datagram header is a round number of bytes.
When an application must send a datagram out on the network, it performs a few simple steps. First, it constructs the IP datagram within the legal lengths stipulated by the local IP implementation. The checksum is calculated for the data, and then the IP header is constructed. Next, the first hop (machine) of the route to the destination must be determined to route the datagram to the destination machine directly over the local network, or to a gateway if the internetwork is used. If routing is important, this information is added to the header using an option. Finally, the datagram is passed to the network for its manipulation of the datagram.
As a datagram passes along the internetwork, each gateway performs a series of tests. After the network layer has stripped off its own header, the gateway IP layer calculates the checksum and verifies the integrity of the datagram. If the checksums don't match, the datagram is discarded and an error message is returned to the sending device. Next, the TTL field is decremented and checked. If the datagram has expired, it is discarded and an error message is sent back to the sending machine. After determining the next hop of the route, either by analysis of the target address or from a specified routing instruction within the Options field of the IP header, the datagram is rebuilt with the new TTL value and new checksum.
If fragmentation is necessary because of an increase in the datagram's length or a limitation in the software, the datagram is divided, and new datagrams with the correct header information are assembled. If a routing or timestamp is required, it is added as well. Finally, the datagram is passed back to the network layer.
When the datagram is finally received at the destination device, the system performs a checksum calculation and[md]assuming the two sums match[md]checks to see if there are other fragments. If more datagrams are required to reassemble the entire message, the system waits, meanwhile running a timer to ensure that the datagrams arrive within a reasonable time. If all the parts of the larger message have arrived but the device can't reassemble them before the timer reaches 0, the datagram is discarded and an error message is returned to the sender. Finally, the IP header is stripped off, the original message is reconstructed if it was fragmented, and the message is passed up the layers to the upper layer application. If a reply was required, it is then generated and sent back to the sending device.
When extra information is added to the datagram for routing or timestamp recording, the length of the datagram can increase. Handling all these conditions is part of IP's forte, for which practically every problem has a resolution system.
IP version 6 (usually abbreviated simply as IPv6 and sometimes called IPNG for IP Next Generation) was designed to address the legacy issues of the older version of IP (called IPv4). The major improvement brought about by IPv6 is the capability to handle much larger address spaces, eliminating any threat of running out of IP addresses. In fact, one goal of IPv6 was to allow individual components of a computer have their own IP address through a hierarchical allocation system, although this is not planned. The extra address length available in IPv6 means that any network address translation requirement has been eliminate, simplifying all aspects of locating specific devices.
From an architecture point of view, IPv6 is not a dramatic change over IPv4, and most transport layer and application layer protocols will need no change, or only a little change, to function in the IPv6 world (the exceptions are applications like FTP that embed network information in their messages).
The major changes brought about by IPv6 can be summarized simply:
· great address space: the address space in IPv6 is 128 bits long, compared to 21 bits with IPv4, and there is no class definitions for IPv6.
· stateless addressing: IPv6 networks can route message automatically using the ICMPv6 discovery messages that send a broadcast to other routers with details of its network
· link-local address: allow links that never change address
· large packet support: allows packets up to 4GB instead of IPv4's limit of 64kB
· no checksum in the header: with IPv4 a checksum is computed with every hop whereas IPv6 does not use error checking in the network layer
As mentioned above, IPv6 addresses are 128 bits long (compared to 32 bits for IPv4). This allows for a huge number of unique addresses. IPv6 addresses are usually written as eight groups of four hexadecimal digits separated by colons. So, while an IPv4 address would be 184.108.40.206 (dotted quad notation), an IPv6 address looks like 192a:0d8e:743b:92f2:a083:cf3e:6fe4:8237. Addressing rules state that if one or more of the four-digit groups is 0000, the zeros can be eliminated and two colons used instead (so 192a:0000:743b:0000:a083:cf3e:0000:8237 could be written as 192a::743b::a083:cf3e::8237). Leading zeros can also be eliminated, as long as at least two colons are in the address (so localhost will always be ::1).
The header itself is 320 bits long (40 octets) containing:
|version: 4-bit IP version||traffic class: a packet priority value||flow label: used for QoS management although unused currently||payload length: number of bytes in the payload||next header: the next encapsulated protocol (compatible with IPv4 values)||hop limit: time-to-live value from IPv4||source address: 128-bit IPv6 address||destination address: 128-bit IPv6 address|
Networks are composed of a collection of devices such as computers, printers, servers, and so on. These devices all send information back and forth over the network, and in theory a network can be made up of a bunch of computers all connected together, each handling information flowing through it. However, in an attempt to offload a lot of the network traffic processing, networks developed specialized devices that are tasked with the movement, analysis and routing of network traffic specifically. These devices are essentially computers themselves, running specialized software, and they go by the names of switches, hubs, gateways, routers, and similar terms.
In their simplest form, these devices are called switches and they have very basic tasks to perform. More complex devices do the same task but can also perform more advanced tasks such as converting protocols, accepting traffic from external networks (these are called gateways, usually), and handling traffic over different types of media (such as connecting Ethernet cables to high-speed ATM backbones).
The goal of all these devices is the same, though: they accept data from the input ports (usually many ports supported simultaneously) and they then route the data to the appropriate output port which may lead to a specific device, a network, or a connection to another network or the Internet. The switch essentially sorts traffic packets, routing them to their intended destination.
Switches and similar devices do their routing based on the computer's physical device number (such as the MAC address or the IP address which is in each frame of data coming in). Using an internal table, the switch knows which output port connects to the destination either directly or indirectly, or, if it doesn't know, it sends the data to another switch that might know. (When you send data from a machine on a LAN through the Internet to another machine on a different LAN, your LAN's gateway has very little chance of knowing exactly how to reach the destination, but it does know how to send the data to a machine that is closer to the destination. That machine then forwards the packet on even closer to the destination. Each step is called a "hop".)
Switches do their tasks at the data-link layer of the OSI model, simply examining a physical address (MAC address) and sending the packet to another device that is closer to the destination. Some switches also perform layer 3 (network layer) analysis, which is where IP addresses are stored. These types of devices are often called "IP switches".
Switches and similar devices form the backbone of the Internet and all larger network connections to the Internet. Core switches are switches that compose a backbone or gateway level, switch talking to switch. Desktop switches are the switches that connect to specific devices.
You have seen the layered structure of TCP/IP and how it relates to the OSI model. You’ve also seen how IP packets are formed, which are then encapsulated by the network (such as Ethernet) for movement. Understanding how IP packets are built is a key to understanding issues with packet movement, packet life, and hop-based issues that networks face all the time.