As mentioned before, the Internet Protocol (IP) layer takes the data handed to it by Transport Layer (usually TCP or UDP) and adds a header to it. The two together are called a datagram, and can be up to 65,536 bytes in length. The header itself is made up of many smaller, definite parts each with a fixed length and definition, plus a number of options which can be up to 40 bytes in length. The datagram, once assembled, is handed down to the Data Link layer (using the TCP/IP model), which gives it to the physical layer, and vice versa on the way back up.

What follows is a list of all of the components to the Internet Protocol version 4 datagram header. In parentheses is the number of bits devoted to the respective element.

 Some of the options available include Record Routing, whereby the source creates an empty list of IP addresses. Then each gateway that handles the datagram adds its IP address to the list. The sender can also specify Source Route Options so that the datagram follows some pre-determined path through the network. Strict Source Routing dictates an exact path, while Loose Source Rating allows for unlimited network hops between given addresses. There is also a Timestamp Option, which asks each intermediate gateway to add their own timestamp to the datagram.

Depending on the relationship of the sender and receiver, datagrams can be transmitted directly or indirectly. When they're both attached physically (i.e.: there's not router separating them) then the sender encapsulates the datagram in a physical frame and maps the destination IP address into a physical address. Then it uses the network hardware to deliver it. Most of the time, the machines are linked only by networks (such as accessing most internet sites) and this forces the sender to pass the datagram to a gateway. When it's an indirect delivery, the sender just identifies the gateway it's using, and the gateway forwards it to the destination network.

While each device connected to the Internet has its own, unique IP address, there are also addresses for networks and other entities. Gateways have as many IP addresses as they connect networks, and each network also has it's own address which will be the host-id will all additional bits at 0. If you wanted to send a broadcast message to all the devices in that network, you'd just send a message to the host-id followed by all 1's. If all bits are 1's then a limited broadcast is sent out to the local network.

The Domain Name System (DNS) was introduced in 1984. It allows character strings to be used in place of IP addresses. When a high level name is requested, it sends the character string to one of the servers, geographically distributed across the world, to map the name to an IP address. Then the IP address is used. This is why you can type access www.earlham.edu instead of having to know 159.28.1.1

One of the big "issues" in the Internet community today is the future protocol of the internet. It runs on TCP/IP right now, the IP being the Internet Protocol we're discussing now. The current version, IPv4 has a 32 bit address field, which allows 4,294,967,296 addresses to be used. This sounds like a lot, but due in a large part to how they were divvied up they are getting close to running out. Give the current expansion of the Internet, they will run out soon, even with tricks like subnet masks and asking those organizations that hold many addresses to return those not being used. This is one of the driving forces behind IPv6, or IPng (next generation). Currently IPv6 has many of the standards either defined or being discussed right now, and indeed there are some servers using it right now. The primary difference that people notice is that it has a 128 bits reserved for addressing. That's 340,282,366,920,938,463,463,374,607,431,768,211,456 (about 3.4*10^38, I think) addresses, which can give each square millimeter on the earth hundreds of thousands. IPv6 is designed for transmitting large amounts of data at very high speeds as well as taking into consideration the much slower transmission speeds of wireless and similar media. Hence, while the addresses are 4 times as large, the total header is a fixed length of 40 bytes, which is longer than most IPv4 headers, but shorter than the theoretical maximum. Also IPv6 has no "options" section, so the header is always a fixed length, making it much faster to process through routers. Options are dealt with in a special layer in between the IP and Transport layer, and most routers just ignore them. Finally, IPv6 is "downward compatible" in the sense that IPv4 addresses can still be used and IPv6 networks can communicate with IPv4s. This will allow organizations to upgrade their equipment (which is designed to be a relatively painless task) and run an IPv6 network internally while accessing the Internet through IPv4. If they access another IPv6 network directly, then they can use that protocol. As organizations upgrade their equipment, the internet can turn more and more to the advanced protocol.

For congestion-controlled traffic, the following Priority values are recommended for particular application categories:
0 Uncharacterized traffic
1 "Filler" traffic (e.g., netnews)
2 Unattended data transfer (e.g., email)
3 (Reserved)
4 Attended bulk transfer (e.g., FTP, HTTP, NFS)
5 (Reserved)
6 Interactive traffic (e.g., telnet, X)
7 Internet control traffic (e.g., routing protocols, SNMP)

For non-congestion-controlled traffic, the lowest Priority value (8) should be used for those packets that the sender is most willing to have discarded under conditions of congestion (e.g., high-fidelity video traffic), and the highest value (15) should be used for those packets that the sender is least willing to have discarded (e.g., low-fidelity audio traffic).

In addition to these there are a lot of extension headers, which are like IPv4's "options" except that they're not counted as part of the header. Instead they are options, each one equal to some multiple of eight octets in length. Here are a few examples:

Look at some definitions.

return to the index
send comments to: Ardenstone@Ardenstone.com