IPv6: What is Internet Protocol?——————————————————————————————

Internet Protocol (IP) is one of many communications protocols that compose the Internet Protocol Suite (IPS) and is arguably the most important protocol. Experts usually describe IPS as a stack of protocols that convert application information (like e-mail or Web traffic) into digital packets capable of traversing networks, including the Internet.

Specifically, IP is responsible for transmitting the digital packets from a source host to a destination host over a network connection. The Request for Comment (RFC) 791 is the last word about IP and provides the following definition:

"The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service."

Packets and datagrams: Is there a difference?

When discussing IP, many people (including me) interchange the terms packet anddatagram as both terms have similar (identical, some argue) definitions. RFC 1594defines a datagram/packet as:

"A self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between the source and destination computer and the transporting network."

Since they're the same, why worry about definitions? Well, sometimes experts define packets differently from datagrams, and that's when it gets confusing. They use the term packet when discussing reliable data transmission protocols such as TCP/IP, and then use the term datagram when talking about best-effort data transmission protocols like UDP. For our discussion of IP, it doesn't matter which term is used, but I'd like to stick with datagram (you'll see why in a moment).

IP attributes

IP has several attributes that define how data is transmitted, and they're important regardless of whether we're discussing IPv4 or IPv6. So, let's take a look at them:

• Host addressing: IP defines the addressing scheme for each host on the network and uses the addresses to facilitate datagram delivery.
• Protocol independence: IP by design is able to work with any type of underlying network protocol using protocol stack technology.
• Connectionless delivery: IP does not set up a relationship between the sending host and the receiving host. The sending host just creates datagrams and sends them on their way.
• Best-effort delivery: IP tries its best to ensure that the receiving host actually gets the datagrams addressed to it, but there are no guarantees.
• No provision for delivery acknowledgments: The receiving host does not acknowledge the fact that it indeed did receive the data addressed to it.

One wonders how IP datagrams get where they're supposed to, when the last three attributes create less than a perfect environment. Why leave those features out of the protocol? The simple reason is better performance. Using established connections, error-checking, and guaranteed delivery require additional processing power and network bandwidth. So if the datagram being transmitted does not require certain attributes, it's better they aren't used. Besides, the people who developed IP are a smart bunch, designing a more efficient approach that uses protocol stacking.

Protocol or TCP/IP stack

If you recall, I mentioned something called a protocol stack (officially TCP/IP) earlier. If the type of transmitted data (such as e-mail) requires guaranteed delivery, receipt acknowledgment, or an official connection handshake, the information is appended earlier in the datagram-building process, or what is called "further up the stack." It turns out to be good solution, especially since it conserves network resources.

On a side note, I debated whether to include information about the TCP/IP stack in this discussion, as we're supposed to be focused on IP. The only problem is that it's very hard to divorce TCP from IP. Especially since a large percentage of datagrams include TCP information.

TCP/IP Guide has an excellent explanation of what a TCP/IP stack is and how it works. The process of encapsulation (ultimately why I included this information) also takes place in the TCP/IP stack. Encapsulation is where the next protocol in the stack encapsulates the datagram, giving it additional information that's required, so the packet can successfully reach its destination. The following diagram (courtesy of TCP/IP Guide) depicts the encapsulation process:

IP datagram format

To get a better understanding of what (besides data) is sent in a datagram, we need to look at the datagram's format. The following diagram (courtesy of TCP/IP Guide) shows all the various fields of an IPv4 datagram. For more information about each field in the datagram, please refer to this TCP/IP Guide link.

As a point of comparison, the next diagram (courtesy of TCP/IP Guide) is the IPv6 datagram format. Once again, for more information about the individual fields, please refer to this TCP/IP Guide link.

It's interesting how the IPv6 datagram format is consolidated and actually makes more sense. For example, changing the TTL field to hop limit is a much better description.

Next time

In this article, I tried to point out the commonalities shared by IPv4 and IPv6, with the exception of the datagram formats. The rest of the series will deal with IPv6, the differences between it and IPv4, and why IPv4 needs to be phased out. If everything works out, the next edition will be a podcast with Mr. Joe Klein, senior security researcher for Command Information and a member of the North American IPv6 Task Force. He'll be discussing why IPv4 is on its last legs.

Final thoughts

I first wanted to thank everyone for all the useful comments and suggestions in my previous article, "IPv6: Where to Begin." This article is the direct result of those comments. Besides, truth be told, I needed a starting point, and a high-level review seemed like a good idea. I hope you agree; now we can move the discussion to IPv6 and all its nuances.

I also wanted to make mention of the Web site TCP/IP Guide. It's written and maintained by Mr. Charles M. Kozierok and, in my world, is one of the best resources for anything dealing with TCP/IP.

Links to Original